Making a few fast paths for drawing bitmaps (BitBlt) would be huge for game developers. I know that 3 of my games I have made aren't OGL simply because I don't want the extra code maintenance/burden. If a game is doing some of the things you mention, well then it's not likely concerned with frame-rate.

On 9/16/2010 2:35 PM, Romain Guy wrote:
Again, it really depends on what the application does exactly. If you
are always drawing the same translucent bitmap on screen, the GPU will
be better. If you are drawing complex shaded and antialiased paths or
you draw a bitmap that changes often, things can get pretty bad. Some
features of the Canvas API require other kinds of expensive operations
(for instance, implementing saveLayer/saveLayerAlpha requires the use
of FBOs or glCopyTexImage2D and neither solution is ideal.)

On Thu, Sep 16, 2010 at 11:20 AM, markusn82<markus...@gmail.com>  wrote:
Thanks for the response. I know that mobile GPUs are tile-based and
aren't great in terms of raw pixel processing power, but the pixel
throughput would definitely be miles ahead of a general purpose CPU.
I'm sure you guys have already considered this angle, but instead of
using OpenGL why couldn't you create a custom 2D graphics library for
vendors to implement at the lower level?

As a side note, I just found a lengthy discussion of this issue here:

http://code.google.com/p/android/issues/detail?id=6914

On Sep 16, 1:50 pm, Romain Guy<romain...@android.com>  wrote:
Hi,

This is something we have investigated several times in the past. The
biggest issue with hardware acceleration of the 2D drawing API is
coverage. Many features offered by the existing 2D APIs are difficult
or extremely expensive to implement using OpenGL. There are also
issues with various OpenGL implementations. As game developers know
very well, different GPUs and OpenGL drivers sometimes behave a little
differently or suffer from different bugs. By using a software
rendering API we can guarantee rendering fidelity across all devices.
There is also the problem that mobile GPUs are not all well suited for
the kind of operations required by a 2D drawing API as currently used
by the Android UI toolkit (fill rate or shaders complexity can be a
problem for instance.)

Hardware acceleration of the drawing APIs is something we would love
to have but it is by no means a magic bullet that's going to solve all
issues.

For what it's worth, window composition is already hardware
accelerated and has been so since Android 1.0.





On Thu, Sep 16, 2010 at 10:36 AM, markusn82<markus...@gmail.com>  wrote:
I've been developing Android application for quite awhile now. Please
correct me if I'm wrong, but as far as I know the UI toolkit and 2D
graphics API aren't hardware accelerated (the official documentation
states that Canvas is not accelerated). I've found that most non-
trivial animation or blending operations are painfully slow even on
mid-level devices like a Droid, even after taking much time to
optimize my code.
I'd like to know what the rationale is for not providing hardware
support for these frameworks? Wouldn't it be possible to at least make
it optional for vendors to implement support? Does anyone have any
additional information about this issue?
Thanks!
--
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
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Romain Guy
Android framework engineer
romain...@android.com

Note: please don't send private questions to me, as I don't have time
to provide private support.  All such questions should be posted on
public forums, where I and others can see and answer them
--
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
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en




--
Leigh McRae
www.lonedwarfgames.com

--
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
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to