pouët.net

Go to bottom

C++ and OpenGL on Windows Phone

category: code [glöplog]
Sidenote:
Quote:
Either way, I wouldn't use that and not have a decent off-line solution as a backup.

A map, a brain and a mouth to ask people is usually enough for me... :)
added on the 2012-03-30 10:53:24 by raer raer
Quote:
A map, a brain and a mouth to ask people is usually enough for me... :)


Haha.. 200% agreed :)

Quote:
So. 200MHz. Really?! I'm not saying a JIT is the solution and a VM can give you the speed of native code, but they're getting closer and it will become more irrelevant in the future.


We've been hearing this pretty much since the late 90s when Java VMs started to see regular use in business and a little later when it started to creep it's way into the first handheld devices.

The problem is that, especially for handhelds, the functionality and multimedia requirements of the devices has simply not stopped evolving at a rapid pace.

So there simply is *no* redundancy left in terms of excess processing power on these devices to accomodate the VM, however good, and still get even near-native performance.

So we're just always crippled by it, even when an application does just use Java or what have you for lightweight code and defers heavy processing to a GPU or native call (most phone apps don't do any kind of heavy processing): there's still some speed wasted and most definately a considerable amount of RAM. Because 20 of these processes run at once today.

And if 10 of those are badly coded (which is realistic alas): exponential increase in footprint.

End of the day: it's just not a realistic solution for the product phone vendors are trying to make. And it remains beyond my comprehension why some developers feel that it is :)

Quote:
Also I haven't really done anything fancy with the NDK, so I can't tell if it's really that crappy.


It's not very comfortable. The NDK itself comes across as a niche to me, which again leads me to believe that the Android team has a lot to learn about usability. Which is weird since I believe that Google is packed with decent developers. At least they should be given what they're shelling out in terms of salary.
added on the 2012-03-30 11:14:23 by superplek superplek
Quote:
End of the day: it's just not a realistic solution for the product phone vendors are trying to make. And it remains beyond my comprehension why some developers feel that it is

When I first heard about Android being a Java VM on top of a Linux kernel, I was like: "WTF?! Are that must be horrible!". Until it got a JIT (2.3.something) it actually was. Now it is at least usable imo. I agree on the wasted cycles, on the concept lacking in some parts.
Anyways. The thing is that Android's there and not going to go away very soon probably... ;)
I hope they can fix the speed, fragmentation, security and API issues and do a more anal check on Apps before they go to the store.

Wonder how ICS performs on my phone btw, let's hope it becomes faster... ;)
added on the 2012-03-30 11:25:22 by raer raer
Btw. How does "Eigen" work in the Android NDK? Anyone experience with that?
added on the 2012-03-30 11:27:42 by raer raer
Quote:
A map, a brain and a mouth to ask people is usually enough for me... :)


In the city yes, but I mostly use it to drive into the mountains. A mouth isn't so much use when there's only sheep to ask :) This is where anything cloud-based tends to fail too, because there's sometimes no phone network at all, never mind 3g.

A paper map is ok, because the phone still gives GPS coordinates even if it's totally offline, but it means stopping to check. Why bother if the phone is there at your side anyway? (Mine is almost always on in the car, because it plays all my tunes too.)
added on the 2012-03-30 11:33:10 by psonice psonice
Quote:
I hope they can fix the speed, fragmentation, security and API issues and do a more anal check on Apps before they go to the store.


Plus an even more anal check for each new device that a phone vendor ships and we'll be on the right track to something that's, yes, usable.
added on the 2012-03-30 11:33:46 by superplek superplek
In my experience, people who slam Java have usually been exposed to J2ME on mobile. J2ME is shit. Java on Android is acceptable, and Java on webservers is often the best possible option, both for speed and scalability. It's all about context :)
added on the 2012-03-30 13:23:10 by gloom gloom
Good to know that today we regard "acceptable" as a quality when it comes to an OS-integrated language. Because battling inherent slowness is a very good use of the chic 4 cores in today's modern phone.

Sad, sad and once again: sad.
added on the 2012-03-30 13:57:59 by superplek superplek
plek: I didn't say it was good on Android, I said it was acceptable -- because it is. :) That said, at work we do all our Android work in C++ (NDK) anyway so we're not really affected by the Java-"issue" because we don't really have to deal with it at all.
added on the 2012-03-30 14:07:17 by gloom gloom
@gloom
Actually I was talking specifically about Java on Android, and my bad experience with it that made me think that it's unacceptable for even minimal floating point computation.
Java on webservers -- yes, under some conditions it can get even faster that native.
added on the 2012-03-30 15:18:10 by provod provod
Quote:
under some conditions it can get even faster that native

is it the cloud thing again? No VM can be faster than native. It can be the same speed, it can't be faster. Native code doesn't imply leaking every single alloc, you know? :P
added on the 2012-03-31 01:50:10 by xernobyl xernobyl
http://www.engadget.com/2012/02/26/orange-santa-clara-intel-medfield/

So, next year, when Intel starts shipping Android phones powered by Atom CPUs, you'll need to provide two different binaries for each architecture for your client's fart app / website app? Java is slower than native code, but it has other advantages. Remember, we're not in Wintel-land anymore, Dorothy.

I envy you for working in an environment where there is time to do proper application memory management. In my work development cost is so high and deadlines so close, there is no time to juggle malloc's and free's. The client simply does not pay that much.

And just what is the percentage of apps people actually use that require serious number crunching? I know I don't use any. But you still have the choice to use the NDK if you must.
added on the 2012-03-31 02:16:10 by moT moT
The C++0x evangelists tend to disagree.
added on the 2012-03-31 03:54:32 by xernobyl xernobyl
@xernobyl
Not VM, but JIT that has enough statistics about runnig the code in question on real production data. Also, if you haven't noticed, I'm the one here for native and against VMs :D.
added on the 2012-03-31 07:07:56 by provod provod
i wonder how big is the java server market share for online games these days. i would assume very small, only old companies with lots of legacy code still walk that road. no?

nginx+nodejs getting a big rise last year aparently. wonder how much of that is new thing hype talk and how much is actual usage.
added on the 2012-03-31 08:29:24 by psenough psenough
Re. Medfield, you can put binaries for more than one architecture in an apk (APP_ABI=ALL). Furthermore you might be surprised at just how well Intel's binary translation technology works.
Well, the original post is very cool...but the thread turned into garbage quickly. Props to the MoSync guys.
added on the 2012-04-01 04:19:18 by shuffle2 shuffle2
[rant]Once you have to write a software renderer for a platform that had its GPU capabilities castrated by the OS developer you should instead go the extra mile and and kick their heads in...[/rant]

Else than that: Hooray for software renderers. Boo to M$.

Topic closed.
added on the 2012-04-01 15:22:17 by raer raer
It's not a software renderer
When microsoft first took a crack at making a JVM, iirc it was pretty good... faster than Sun's but sun sued them. Microsoft's Eric Traut has done great work with JIT stuff, and even has some patents in that area. So far as I understand, MSIL/CIL has never been anything like this.

Programmable shaders where promised for Windows Phone from the very beggining, so I am surpised that they still do not allow that.

added on the 2012-04-02 03:56:48 by QUINTIX QUINTIX
I confused the XNA->OGL conversion and the software shaders. sorry.
added on the 2012-04-02 11:17:21 by raer raer

login

Go to top