> 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
