honeycomb is also slower.
congratulations google.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
How did you exactly determine this?
On Feb 24, 11:25 pm, sblantipodi perini.dav...@dpsoftware.org wrote:
honeycomb is also slower.
congratulations google.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email
:)
On Thu, Feb 24, 2011 at 8:55 PM, sblantipodi
perini.dav...@dpsoftware.orgwrote:
honeycomb is also slower.
congratulations google.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
Not to mention that testing OpenGL games is impossible. The only way
to test on devices is users, otherwise it's just a guessing and hoping
for the best.
In any case, I don't care WHY the emulator is so slow. Hopefully
they'll make it fast in the near future, the iPhone emulator is much
better.
(and yes, you can
run 8-bit pacman full speed on far slower devices - i.e. Spectrum
emulator on Palm phone (which is 300MHz).
I meant if Pacman's 8080 were running at 1GHz. No way it could be
emulated at full speed on a 2GHz i86, if each instruction is emulated
individually -- not even close.
On Sat, Jan 29, 2011 at 1:26 AM, Miguel Morales therevolti...@gmail.comwrote:
Not to mention that testing OpenGL games is impossible. The only way
to test on devices is users, otherwise it's just a guessing and hoping
for the best.
In any case, I don't care WHY the emulator is so slow.
It's easy to say that until you have actually written an OpenGL game for
Android. Running at seconds per frame instead of frames per second
means you can ONLY test on real hardware. On real hardware my game
(Tank Recon 3D) takes over 5 minutes to load in the debugger (30 seconds
on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2011 10:55 AM, Leigh McRae wrote:
It's easy to say that until you have actually written an OpenGL game for
Android. Running at seconds per frame instead of frames per second
means you can ONLY test on real hardware. On real hardware my
iOS simulator is fast because XCode builds an X86 binary and because
iPhone and OSX both run basically the same OS, there is no actual
emulation happening, mostly just API mapping... It's running as a
mostly OS-Native binary.
Unless you want to develop your apps in Android itself on your desktop
Other emulators works with natively speed, don't compare a 1GHz Cortex
or Snapdragon processor
with a modern desktop CPU please, its ridiculous.
@Raphael: Thanks for the answer, I appreciate your answer and hope to
see some fix soon :)
On Jan 28, 3:44 am, Zsolt Vasvari zvasv...@gmail.com wrote:
I'm not complaining about the performance, since I know the problems
behind it.
But, with the inevitable performance problems maybe a simulated
environment(with x86 architecture) or a Android x86 VM would be a
better option(in performance).
Problems will probably arise with the optimisations of
Thanks for the lesson, I didn't realize that a 1GHz Cortex is not
directly comparable to a 2GHz Core i3...
All I was trying to say that emulating of 1GHz of any non native code
at the instruction level will be slow on a 2Ghz host. I'd bet if you
tried to run a PacMan 8-bit CPU at 1GHz, it
All I was trying to say that emulating of 1GHz of any non native code
at the instruction level will be slow on a 2Ghz host. I'd bet if you
tried to run a PacMan 8-bit CPU at 1GHz, it wouldn't emulate at full
speed or even come close.
8-bit or not is not directly related to possible emulation
As Dianne mentioned and others have before, the bottleneck is the
dynamic translation of ARM opcodes to x86 opcodes. Other VM's like
Vmware emulate hardware, but they are still executing code natively
albeit with some hypervisor that itself has direct hooks within modern
processors. The WebOS and
Performance problem on android SDK isn't related on what you are
talking here.
Android SDK is so slow also with android 2.2 and 2.2. The SDK uses
only one core
and this is a shame.
Too slow for everything that needs more power than a fart app.
--
You received this message because you are
I agree, the SDK itself is slow, not just the emulator. I've noticed
that with every release of the SDK it gets slower.
-niko
On Jan 27, 6:56 am, sblantipodi perini.dav...@dpsoftware.org wrote:
Performance problem on android SDK isn't related on what you are
talking here.
Android SDK is so
On Thu, Jan 27, 2011 at 12:16 PM, niko20 nikolatesl...@yahoo.com wrote:
I agree, the SDK itself is slow, not just the emulator. I've noticed
that with every release of the SDK it gets slower.
The SDK is a ZIP file (or a self-installing EXE on Windows). ZIP files
do not have speed and hence
I have the same problem with all AVDs, regardless of the version.
The emulator in general sucks in performance.
I'm on 64 bit Ubuntu, bus same goes for Windows XP and Windows 7.
On 27 янв, 03:58, Jake Basile jakerbas...@gmail.com wrote:
I have a Core i7-920, 6GB of DDR-1333 RAM, and an ATI
We are aware of the emulator speed issue and are actively working on it.
R/
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email
Honestly, what do people expect? You are trying to emulate a 1GHz
computer on a 2GHz computer with a completely different architecture.
I can't imagine it will ever be fast. I used do MAME development and
can tell you that it's hard to get the emulation running for even a 10
year old system with
Odd, I've never had any real trouble with the performance. The first
time the emulator comes up is always painful, but once it's configured
everything else is reasonably swift.
On Jan 26, 7:35 pm, sblantipodi perini.dav...@dpsoftware.org wrote:
As title.
I think that Androdi SDK should think
I have a Core i7-920, 6GB of DDR-1333 RAM, and an ATI 5770. I get maybe 5-10
FPS on the Honeycomb emulator. This thing needs serious performance testing
and improvement.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this
The issue with HC is that it now has a huge screen to draw, and the emulator
itself doesn't implement any hardware acceleration of drawing, so it needs
to emulate ARM code that is rendering to a window, and then emulate yet more
ARM code that composites together the final display.
Implementing
And wouldn't you like to have *some* kind of working HC emulator now before
devices ship?
I just wanted to say yes, absolutely. Thanks for getting this to us
soon, even in an unfinished/preview state rather than making us wait
for the device to ship and our apps to be broken on customers
24 matches
Mail list logo
