H-m-m-m. Interesting point. Emulating a 1Ghz CPU on a 2Ghz CPU is
bound to be slow. But given that, I would be still be happy if the
emulator were only 1/25th the speed of the emulated system (I have
dealt with worse). It is still, after all, faster than waiting for a
developer version;)
On Feb
Suspect we are talking at cross-purposes. If you have switched Canvas to
GL-based rendering then surely it is self-evident that there is going to be
far more computation overall (i.e. for both hardware *and* software) in
using a complex floating-point based pipeline. For the emulator, that
Reuben, the emulator does NOT use the new OpenGL backend for Canvas. It
wouldn't work on the emulator anyway because it requires OpenGL ES 2.0 and
the emulator does not support OpenGL ES 2.0. The emulator is slow simply
because there are more pixels to draw and apps are more complex than
before.
That does surprises me, considering the triangular tearing seen on the
Honeycomb emulator. I guess that was just framebuffer composition.
Thanks for the clarification.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group,
I would like to have more respect about your work but the answer from
Romain Guy doesn't respect our patience.
This SDK is simply UNUSEFUL, google save your time if you need to
write a simulator like this,
no one can use it because is too slow also for a fart app, it's
unusable.
If you can't do a
The problem is that the emulator is an emulator, not a simulator, nor does
it virtualize your computer's CPU. Tools like VMWare or VirtualBox achieve
great performance thanks to virtualization, apps in the guest OS run
directly on your hardware CPU. In the case of Android's emulator, a
completely
Nice though that fix would be, to date, there has been a reasonable
workaround for the emulator slowness: launch once at the beginning of
your work session and don't kill it.
As long as the emulator can be set back to a last-known-good-state,
such a workaround is livable. What is not livable is
I bought the Xoom cuz I was unable to program and test my code
effectively on the emulator. I wish we can get one for a discounted
rate or one that's not tied to Verizon for developers.
On Feb 24, 4:09 pm, Indicator Veritatis mej1...@yahoo.com wrote:
Nice though that fix would be, to date,
I second this. The emulator is unusable for Xoom and I wouldn't hold
ny breath for any significant improvements in the speed of the
emulated machine, no matter what Romain is saying. Even if they
manage to double the speed of the emulator, it would still be pretty
much unusable. You will never
I still cannot maintain landscape on OS X. It will switch but then revert
2-3 seconds later. :-(
On Wed, Feb 23, 2011 at 1:55 PM, Romain Guy romain...@android.com wrote:
And my point is that Canvas.drawBitmap() etc. is not doing any more
computation than previous SDKs.
On Wed, Feb 23,
How does that have anything to do with the speed of the emulator?
On Feb 24, 3:17 am, Stacy Young styoung.li...@gmail.com wrote:
I still cannot maintain landscape on OS X. It will switch but then revert
2-3 seconds later. :-(
On Wed, Feb 23, 2011 at 1:55 PM, Romain Guy romain...@android.com
I suspect Honeycomb emulator's performance is being crippled by every last
pixel now having to go through a pure software OpenGL pipeline. That will
have far more stages than the old 2D renderer had.
If you ever ran an OpenGL ES app on older emulators, you'd see similar
slowness... there is
The Honeycomb emulator is faster on my dev system than the preview
was, but it is highly sensitive to the emulated hardware. I am using
1024 megabytes of emulated RAM and a 256 meg vm heap size and I still
see out of memory errors when the launcher tries to load wallpaper.
The AVD refuses to go
Window composition was already done in software OpenGL before, and the new
hardware acceleration layer for 2D rendering inside apps is not turned on in
the emulator.
On Wed, Feb 23, 2011 at 3:54 AM, Reuben Scratton
reuben.scrat...@gmail.comwrote:
I suspect Honeycomb emulator's performance is
My point was that ordinary drawing - Canvas.drawBitmap() etc - will now be
doing at least 3x as much computation per pixel than in previous SDKs, hence
the slowdown (or so I'm guessing). Not to mention there are now rather more
pixels than there used to be.
I doubt if window composition is a
And my point is that Canvas.drawBitmap() etc. is not doing any more
computation than previous SDKs.
On Wed, Feb 23, 2011 at 9:42 AM, Reuben Scratton
reuben.scrat...@gmail.comwrote:
My point was that ordinary drawing - Canvas.drawBitmap() etc - will now be
doing at least 3x as much computation
I completely dumped the emulator a couple of years ago, but with honeycomb,
not much choice, it's all been very slow and painful. On the plus side the
eclipse-plugin is getting a lot more functional.
After running the latest updates this morning (android and eclipse), it
takes three or four
17 matches
Mail list logo
