Re: [android-developers] Hardware accelerated Canvas.drawPicture support (or recommended alternatives)

It's exactly what the WebView does and it's usually the best approach
when you have possibly hundreds of graphics primitives. Note that the
way we use display lists in the UI toolkit allows for fast and
efficient culling.

On Sun, May 27, 2012 at 10:26 AM, Josh Guilfoyle <jasta00@gmail.com> wrote:
> Thanks for the quick reply.  Given your last comment about rasterization of
> Path, I think an appropriate option is to just disregard hardware
> acceleration for most of what I'm doing and render the full graphic into a
> set of tiles.  The hardware renderer can optimize the "last mile" step for
> me by efficiently copying and scaling my tiled bitmaps onto the display.
>
> I will also do some performance benchmarks to get a sense for how expensive
> drawing the Picture is versus culling only the portion of the full graphic I
> need.  Hopefully it's negligible.
>
>
> On Sunday, May 27, 2012 9:46:03 AM UTC-7, Romain Guy (Google) wrote:
>>
>> > 1. What performance gotchas may exist with simply constructing my own
>> > macro notion of a Picture and replaying the raw Canvas operations on
>> > draw?
>>
>> Not much really. The UI toolkit has its own equivalent of Picture called
>> DisplayList. If you render a View with on draw() the toolkit builds such a
>> display list and keeps it until the next invalidate.
>>
>> > 3. What is the runtime nature of attempting to draw paths and
>> > primitives (lines, rects, etc) that are entirely outside the canvas'
>> > clipped bounds?  Is it necessary or appropriate for me to call
>> > Canvas.quickReject myself or can I rely on this rejection happening at
>> > a lower level automatically?
>>
>> It will happen automatically but you can save a bit of work by doing it
>> yourself early on.
>> >
>> > If anyone has other suggestions for things I didn't consider please
>> > feel free to let me know.
>>
>> Just one: path rendering can be very inefficient on the GPU. Currently
>> only rectangles and lines are implement natively, all other types of shapes
>> are rasterized with the software renderer into a GL texture. If your paths
>> change often, performance will be pretty bad.
>>
>>  I'm hoping to drive toward an elegant and
>> > efficient solution that works optimally on newer hardware but with
>> > "acceptable" performance on other devices.
>> >
>> > --
>> > 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+unsubscribe@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/android-developers?hl=en
>
> --
> 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+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en



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