So this isn't really an issue of you're doing things that hurt
performance when HA is used, since the exact same code works much better
on other devices (HTC, Samsung and Motorola devices) except the Galaxy
Nexus.
Actually it is possible. Specific commands can run well on some GPUs and
Hi Guy, thanks for the reply
Though it does make sense, i'm not seeing it happening.
I'm not using any special effects on that ListView and i've also tested on
a Samsung Galaxy S2 (i9100G), which has the same GPU and CPU (though a
slightly older chipset) and unlike the Nexus, it gets a major
The Samsung Galaxy S2 has a Mali 400 form ARM, Galaxy Nexus has an SGX540
from IMG. These are two very different GPUs. Again, without knowing what
the apps does I cannot say more about what's going on (also, all the apps
we ship with the default build use hardware acceleration and perform better
ahmm... i've got a couple of those and i'll have to check, but i'm pretty
sure the one i used to test on is actually the 9100G (the international
version), which has the SGX540 :)
Regarding the issue, the list i noticed the slowdown on just has a couple
of TextViews and and a couple of ImageViews
Jelly Bean fixed all the canvas slow down on primitives when hardware
acceleration is on.
This is the evidence that there was a problem in your is that you don't
advertised ;)
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this
I read through the entire thread and it's too bad it got sidetracked into
blaming the slowdowns on the type of functions used in the Canvas instead
of the original intent of saying the Galaxy Nexus (as the device) is having
issues with Hardware acceleration.
I've noticed the same issues as
On Thu, Feb 9, 2012 at 7:23 PM, ji fei ufo22940...@gmail.com wrote:
Seems that hardware acceleration will cost some ram. About 8m per app.
This depends very much on the GPU. The driver for the GPU used in the
Galaxy Nexus and Nexus S has this fixed overhead, others don't.
--
Dianne Hackborn
They do say developer options and it is a developer phone so I would hope they
never get removed from the Galaxy Nexus firmware.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
Seems that hardware acceleration will cost some ram. About 8m per app.
On Fri, Feb 10, 2012 at 9:19 AM, bradgog gogat...@gmail.com wrote:
They do say developer options and it is a developer phone so I would hope
they never get removed from the Galaxy Nexus firmware.
--
You received this
ram too slow
On Fri, Feb 10, 2012 at 11:23 AM, ji fei ufo22940...@gmail.com wrote:
Seems that hardware acceleration will cost some ram. About 8m per app.
On Fri, Feb 10, 2012 at 9:19 AM, bradgog gogat...@gmail.com wrote:
They do say developer options and it is a developer phone so I would
just curios...
the experimental developer options on the new Galaxy Nexus cause
lots of confusion and problems with my users (as the FORCE CPU
RENDERING) do not work with my app (and as i heard from lots of other
developers, even has probs with their apps.
Will this feature even be available in
Would it be possible to have the framework batch rendering operations
automatically by using some kind of retained mode rendering, to make
life easier for developers?
/Tobias
On 17 Jan, 00:47, Romain Guy romain...@android.com wrote:
I Romain I really appreciate your effort to help me, really
On Wed, Jan 25, 2012 at 4:44 PM, Tobias tobias.dub...@gmail.com wrote:
Would it be possible to have the framework batch rendering operations
automatically by using some kind of retained mode rendering, to make
life easier for developers?
/Tobias
This would be making a choice that would
Fps2D does not show any change when you turn on or off the setting on
a GN.
On Jan 16, 11:09 pm, Zsolt Vasvari zvasv...@gmail.com wrote:
Holy macaroni
What a thread.
Let's take an anology:
First vehicle: A bicycle. You can go reasonably fast with it by the
power of a single human.
Some benchmark data in Galaxy Tab 10.1 and Nexus S, source code:
https://github.com/rogeryi/0xbench_2d_hw (modified from 0xlab's benchmark
app).
Samsung Galaxy Tab 10.1 (3.2)Draw Canvas (texture/gradient/color)
Draw Circle2 (texture/gradient/color)Draw Rect
(texture/gradient/color)
On Mon, Jan 16, 2012 at 11:16:20PM -0800, Zsolt Vasvari wrote:
Once again, I was just trying to illustrate that you can bring the
fastest system to its knees by doing stupid things.
Ah, ok. I didn't read it that way, obviously. :-) But then, I've
seen so many absurd claims in this thread by
You realize that going from 10 fps to 30 ftp is an INCREASE in
performance, right?
How are you measuring that? Have you instrumented your code with
timing information?
On Jan 16, 10:41 am, sblantipodi perini.dav...@dpsoftware.org wrote:
Just to add some more data.
This simple app can render
Every apps that uses canvas are slowed down when this acceleration is
enabled.
Watch the memory size balloon fantastically too.
Pent
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
Watch the memory size balloon fantastically too.
That is an unfortunate but necessary side effect. Note that the system
will pretty aggressively free up that memory whenever the user
switches to another app.
--
Romain Guy
Android framework engineer
romain...@android.com
--
You received this
Watch the memory size balloon fantastically too.
That is an unfortunate but necessary side effect. Note that the system
will pretty aggressively free up that memory whenever the user
switches to another app.
It balloons to such a degree that it should really be noted in the
documentation
There is some failure in the android hardware implementation, this is
sure.
It is not possible that a 1.2GHz dual core processor with 1GB of RAM
and a SGX540 isn't able
to run a simple and light software like mine in a smoothly way.
I run that code on feature phones with less than 200MHz with a
On Sun, Jan 15, 2012 at 07:18:37PM -0500, Kristopher Micinski wrote:
I think Romain Guy was looking for specific examples from the stock
Android apps. You said that *all* apps slowed down, if some random
market app slows down, that's not really unexpected, if you can
substantiate your claim
Does your application use any of the canvas functions known not to be
hardware-accelerated? This blog article lists them, along with some best
practices for Android 2D hardware acceleration.
http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.html
--
You received
No my apps uses really simple primitives.
On 16 Gen, 13:30, sparky spar...@google.com wrote:
Does your application use any of the canvas functions known not to be
hardware-accelerated? This blog article lists them, along with some best
practices for Android 2D hardware acceleration.
...and all that primiteves are hardware accelerated.
On 16 Gen, 13:30, sparky spar...@google.com wrote:
Does your application use any of the canvas functions known not to be
hardware-accelerated? This blog article lists them, along with some best
practices for Android 2D hardware acceleration.
The most disappointing thing is this problem is that google don't want
to admit
that they have problem in their implementation, this will probably
means that we
will not see any fix soon.
As I repeat the same canvas runs great on feature phones with 180MHz
CPU and 1MB of heap,
runs great of low
Can you share some source code that reproduces this performance issue?
On Mon, Jan 16, 2012 at 3:53 PM, sblantipodi
perini.dav...@dpsoftware.org wrote:
The most disappointing thing is this problem is that google don't want
to admit
that they have problem in their implementation, this will
No code is needed, every code that draw something on a canvas is
slowed down.
just take a look at the wallpaper also...
Wallpaper that runs fine on Galaxy S with gingerbread runs choppy on
Galaxy Nexus (double the horse power).
Take a look at the widget on 4.0.2... The widget selection area of
Well, I just tried hardware acceleration out on my Nexus S running the
stock ICS and everything that can possible be hardware accelerated is
working fine. There is no lag in the wallpapers or widget selection or the
pre installed apps. There were a couple of apps that didn't do well but
they are
You understand that it's both insulting and ignorant to insult
somebody's implementation without providing substantiation for your
accusations..., correct?
Especially when everyone else here believes you are wrong...
kris
On Mon, Jan 16, 2012 at 10:45 AM, sblantipodi
On Mon, Jan 16, 2012 at 07:45:52AM -0800, sblantipodi wrote:
No code is needed, every code that draw something on a canvas is
slowed down.
Repeating my previous post...it does NOT do this on my Acer Iconia A500
tablet. This makes your claim that it's a bug in Android overall a bit
dubious, to
Invalid test. You didn't use the same device type. To be a valid
test, you need to run the test using two of the same device, side by
side, one running Gingerbread and one running Honeycomb.
Jim, the Galaxy Nexus is the new flagship device. It comes pre loaded with
ICS. It's a phone.
I don't know where is the problem and I'm not insulting anyone,
I'm only saying that there is huge performance problem on the latest
ICS flagship
when hardware acceleration is on.
The problem is present in:
1) Most of 3D wallpaper
2) Most of third party apps that uses paint more than native
Just to add some more data.
This simple app can render its UI at 60FPS on Galaxy Nexus running
stock 4.0.2 with HW ACC is OFF.
https://market.android.com/details?id=MortgageCalculatorPRO.DPsoftware.orgfeature=search_result#?t=W251bGwsMSwyLDEsIk1vcnRnYWdlQ2FsY3VsYXRvclBSTy5EUHNvZnR3YXJlLm9yZyJd
FWIW:
One of my apps, WiFi Manager has a very simple graphical network view:
https://lh4.ggpht.com/RAtqQLlAi6N-oiLg_B6HIKL3ltk0Flb7y52-GRIHz4F7s5Ob4lg8gRpCQ2z1fbSLmQ
( it's taken on a 2.* phone, but you get the idea ).
I just added some profiling code and tried it on a Sony Tablet S, 10,
Ok, the numbers from a Galaxy Nexus with 4.0.2:
hw accel off: animated frames take 7-10-13 ms.
hw accel on: animated frames take 2-3-4 ms.
The widget / app selector on my Galaxy Nexus does stutter somewhat,
but if I scroll it all the way and then back again, it then animates
much smoother.
There is nothing magical about hardware acceleration. It is perfectly
possible to write code that runs faster on the CPU that on the GPU.
For instance, an app that does dozens or hundreds of calls to
Canvas.drawLine() per frame is likely to perform worse on the GPU. The
reason in this particular
sblantipodi wrote:
Simply enable hardware acceleration and the framerate drops from 10FPS
to 30FPS.
That is not a drop. 10FPS (frames per second) is slower, 30FPS is faster.
So, hardware acceleration makes the rendering faster, as expected.
I don't understand what you mean.
Regards,
Per
I wrote wrong.
I meant that the framerate dropped from 10 to 30FPS, with hw off the
framerate was 60FPS.
On 16 Gen, 21:03, Per Larsson perlarsso...@gmail.com wrote:
sblantipodi wrote:
Simply enable hardware acceleration and the framerate drops from 10FPS
to 30FPS.
That is not a drop.
As I saied the same code runs great on every feature phones from JP5
to JP7 and newer.
SAME CODE means that I converted the JavaME calls to android one, we
are talking about exactly the same code.
We are talking about 100-180MHz phone and Is this your answer?
The app isn't well optimized?
You are
Sounds to me like the mystery is solved. Romain explained how calling
drawLine is faster on the CPU, and suggested a way to change the code
to make it more GPU-friendly. In other words, no, the code is not
well-optimized _for GPU rendering_. Perini explained drawLine gives
better-looking results,
On Mon, Jan 16, 2012 at 11:09:55PM +0530, Raghav Sood wrote:
Invalid test. You didn't use the same device type. To be a valid
test, you need to run the test using two of the same device, side by
side, one running Gingerbread and one running Honeycomb.
Jim, the Galaxy Nexus is the new
On Mon, Jan 16, 2012 at 10:26:06AM -0800, sblantipodi wrote:
I don't know where is the problem and I'm not insulting anyone,
I'm only saying that there is huge performance problem on the latest
ICS flagship when hardware acceleration is on.
No, before you very clearly said that Google's
Got it.
Thanks
I understand that...and I knew that when writing my post. The OP said
that the problems started with Honeycomb, so I rolled in Honeycomb
tablets as well. Understand now?
If not, here it is in a nutshell:
You can't compare ONE device running Froyo or Gingerbread with
On Mon, Jan 16, 2012 at 10:41:10AM -0800, sblantipodi wrote:
Just to add some more data.
USELESS data until you repeat the test on many other devices.
This simple app can render its UI at 60FPS on Galaxy Nexus running
stock 4.0.2 with HW ACC is OFF.
Simply enable hardware acceleration and
As I saied the same code runs great on every feature phones from JP5
to JP7 and newer.
SAME CODE means that I converted the JavaME calls to android one, we
are talking about exactly the same code.
We are talking about 100-180MHz phone and Is this your answer?
The app isn't well optimized?
The widget / app selector on my Galaxy Nexus does stutter somewhat,
but if I scroll it all the way and then back again, it then animates
much smoother.
Based on this, I'd think it's the app / widget icon cache population,
not the drawing.
There are stutters at times in the app/widget
It seems on official Android 4.0.2 on the GN there's a slight stutter
when starting to scroll a page for the first time, but removing the
call to setLayerType(LAYER_TYPE_HARDWARE, null); does prevent
the stutter. I didn't notice a difference on AOSP Android 4.0.3 on the
GN (and
Comparisons like this are meaningless if you don't specify the screen
resolution. An app running well on a slow CPU can run much faster at a
low resolution than the same app running on a fast CPU at a high
resolution.
I Romain I really appreciate your effort to help me, really thanks for
this
You still have provided no real proof, code or examples which is continuing to
make you look bad.
--
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
I answer you with a question.
Why the same code runs better on other OSs with 20x less the power,
gingerbread included?
On 17 Gen, 00:15, bradgog gogat...@gmail.com wrote:
You still have provided no real proof, code or examples which is continuing
to make you look bad.
--
You received this
Adding some more data for Romain.
The same software runs at lightning speed on Galaxy Note (1280x800)
and it runs slow
on Galaxy Nexus (1280x720). Do you really tell us that it is the CPU/
GPU hardware difference
to make a simple software like that runs slow, good, or smooth as
butter?
--
You
I Romain I really appreciate your effort to help me, really thanks for
this
but I don't know if you are trying to avoid to admit an android flaw
or if
you are convinved of what you are saying.
I am not avoiding anything but you have failed to far to provide me
with something I could use to
With or without hardware acceleration in this test? If it's with, note
that the Galaxy Note has a better GPU.
On Mon, Jan 16, 2012 at 3:46 PM, sblantipodi
perini.dav...@dpsoftware.org wrote:
Adding some more data for Romain.
The same software runs at lightning speed on Galaxy Note (1280x800)
I am not avoiding anything but you have failed to far to provide me
with something I could use to find such a flaw and fix it.
I have provided you three lines of code that works bad as the other
primitives.
Me neither, but you could be bandwidth limited for instance. Again,
the CPU has
Without.
We are talking about software that runs on feature phones, don't
forget it.
I think that this horse power run-up is becaming ridiculous.
If ICS is slower than gingerbread or other OS we don't need a better
hardware
we need a fix since we are talking about some stupid software that
draws
On Mon, Jan 16, 2012 at 6:57 PM, sblantipodi
perini.dav...@dpsoftware.org wrote:
I am not avoiding anything but you have failed to far to provide me
with something I could use to find such a flaw and fix it.
I have provided you three lines of code that works bad as the other
primitives.
Me
Holy macaroni
What a thread.
Let's take an anology:
First vehicle: A bicycle. You can go reasonably fast with it by the
power of a single human.
Second vehicle: A Ferrari with a fifth wheel powered by a pedal.
Which one is faster? The point is, the Ferrari has 10,000x times the
Or let's take a networking example (since the communactions between a
CPU and the GPU is a network)
Which one is faster?
Sending a 1MB file in ONE CHUNK over a 56kbps dial-up line or sending
the same file, ONE BIT AT A TIME, using TCP/IP over high speed
internet? My guess is the former...
On
this is the example I pointed out, s/network/filesystem :-)
(I apologize if the smiley is passive aggressive, it's not intended that way..)
kris
On Mon, Jan 16, 2012 at 11:15 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
Or let's take a networking example (since the communactions between a
CPU
On Mon, Jan 16, 2012 at 08:15:50PM -0800, Zsolt Vasvari wrote:
Or let's take a networking example (since the communactions between a
CPU and the GPU is a network)
Which one is faster?
Sending a 1MB file in ONE CHUNK over a 56kbps dial-up line or sending
the same file, ONE BIT AT A TIME,
No, need to get your panties in a bunch, I was just making a
point I am sure, if you wanted to, you could use a packet to
transmit a single bit.
I didn't think through the math, because the latency in theory could
be iinfinite So, yes, it's concievable that a 56k modem is faster
if it
This is what I saied, every apps seems to be slower.
Sincerely I am trying many apps and every apps seems slower when
hardware acceleration is on.
I really don't find any improvements in this hardware acceleration
on android platform.
On other OS it clearly boost performance, on android it slow
All the standard apps use hardware acceleration and we've measured
large performance improvements. What apps exactly are slower using
hardware acceleration?
On Sun, Jan 15, 2012 at 1:45 PM, sblantipodi
perini.dav...@dpsoftware.org wrote:
This is what I saied, every apps seems to be slower.
All apps that heavily use canvas to draw something like drawLine(),
drawRect(),
and other primitives.
I'm not the only one who is experiencing the problem, there are many
other developers
that are experiencing the problem also on honeycomb with tablets. XDA
is full of complaining
about this
Please tell me about specific examples so I can see why it is so.
On Sun, Jan 15, 2012 at 2:25 PM, sblantipodi
perini.dav...@dpsoftware.org wrote:
All apps that heavily use canvas to draw something like drawLine(),
drawRect(),
and other primitives.
I'm not the only one who is experiencing the
One examples:
https://market.android.com/details?id=MortgageCalculatorPRO.DPsoftware.orgfeature=search_result#?t=W251bGwsMSwyLDEsIk1vcnRnYWdlQ2FsY3VsYXRvclBSTy5EUHNvZnR3YXJlLm9yZyJd
there a dozens of similar app that is slowed down by hardware
acceleration.
On 15 Gen, 23:31, Romain Guy
I think Romain Guy was looking for specific examples from the stock
Android apps. You said that *all* apps slowed down, if some random
market app slows down, that's not really unexpected, if you can
substantiate your claim by pointing out an app running on many devices
because it comes preloaded,
68 matches
Mail list logo
