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 > -- 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
