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