So, with the new hardware accelerated pipeline, in the case where there could be *thousands* of drawing calls (such as drawLine(s) or drawPath) is it better to not draw to a bitmap cache but rather issue those calls directly to the Canvas provided by onDraw()? What about when scrolling? Should a bitmap cache be used then, or should all the draw calls be continually re-issued while scrolling?
I understand (and have seen) how this is slow when not using hardware acceleration, but I don't understand the new rendering pipeline and internal use of DisplayList enough to know which is the proper implementation (and I would love to understand it better!). My gut wants to use a bitmap cache, but you made it sound like with the hardware acceleration pipeline you shouldn't have to? Thanks, Andrew On Sat, Jan 21, 2012 at 12:14 PM, Andrew Hughes <[email protected]> wrote: > Thanks. > > It does as of API level 12 (Android 3.2.) I would recommend you switch >> to using hardware AA lines if possible (all devices that shipped with >> API level 11 should have now be upgraded to 12.) Make sure to use >> drawLines() as well to batch the geometry. > > > Unfortunately both devices I have (HTC Jetstream and Lenovo ThinkPad > Tablet) are still on API 11...and at least in the case of the ThinkPad > Tablet, what I've heard is that they're skipping API 12 and going straight > to ICS which won't be out until March or later... > > As for using Canvas.drawLines(), the width of the lines I am drawing is > constantly changing (based on the pressure level provided by the active pen > on the tablets I mentioned above). With hardware acceleration, is it > practical to make (a lot) of draw lines calls (changing the stroke width of > the provided Paint in between calls), instead of creating a Bitmap cache > and updating just the region of the Bitmap that changed? I don't know > enough about graphics (and how the DisplayList stuff works) to see how (or > if) this is faster. What about when invalidating the entire Canvas (such as > when scrolling), is it faster to redraw the entire canvas via drawLines() > or to just translate a Bitmap cache? My gut wants to say that the Bitmap is > faster...but I really don't know (remember it could potentially be *a lot* of > lines...depending on how much the user draws). > > I know for sure using a Bitmap cache is faster than drawing everything in > software (using Skia) since I have observed it (and that at least makes > sense to me). > > It would be nice if there were a drawLines() that took an array of line > widths as a parameter instead of using the stroke width in the provided > Paint object :) > > Since you are doing your own buffering I would recommend you keep >> track of the dirty region yourself. Note that you could instead set >> your View's layer type to be LAYER_TYPE_SOFTWARE. If you do so, the >> View will be drawn into a Bitmap for you *and* the clip rect in >> onDraw() will be the same as when you call invalidate(Rect). >> Note however that the rendering engine will have to upload the entire >> bitmap as a texture which can be expensive. > > > I started with using LAYER_TYPE_SOFTWARE, but I was running into problems > where calling invalidate(Rect) still set the clip in onDraw() to the entire > Canvas (http://stackoverflow.com/q/8686525/287575). So I decided to try > implementing the drawing cache myself and test enabling hardware > acceleration to keep all overlapping views from being invalidated just > because one of them is. I also tried keeping track of the dirty region > myself and setting the clip to the dirty region in onDraw() (with hardware > acceleration enabled) but then I was *only* seeing the dirty region being > drawn each time...as if the Canvas was being cleared by the framework each > time (that's what I meant by a "blank Canvas" in one of my previous posts). > > Thanks, > Andrew > > > On Fri, Jan 20, 2012 at 1:51 PM, Romain Guy <[email protected]> wrote: > >> > The reason for this is one of the things I'm drawing in the View are >> lines >> > (potentially lots of them), and hardware acceleration does not support >> AA >> > for drawing lines. >> >> It does as of API level 12 (Android 3.2.) I would recommend you switch >> to using hardware AA lines if possible (all devices that shipped with >> API level 11 should have now be upgraded to 12.) Make sure to use >> drawLines() as well to batch the geometry. >> >> > So, I draw everything to a Bitmap cache and simply update >> > a section of the Bitmap cache when the View's data is updated, then I >> call >> > invalidate(Rect) hoping to only update the View's Canvas with that >> portion >> > of the Bitmap cache that was updated. But I end up redrawing the entire >> > Canvas every time. This ends up being a lot slower than doing the same >> > technique without hardware acceleration enabled. >> >> Since you are doing your own buffering I would recommend you keep >> track of the dirty region yourself. Note that you could instead set >> your View's layer type to be LAYER_TYPE_SOFTWARE. If you do so, the >> View will be drawn into a Bitmap for you *and* the clip rect in >> onDraw() will be the same as when you call invalidate(Rect). >> >> Note however that the rendering engine will have to upload the entire >> bitmap as a texture which can be expensive. >> >> -- >> Romain Guy >> Android framework engineer >> [email protected] >> >> -- >> 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
