I am hoping to use the svg-android project to implement a dynamic SVG viewer for files with fairly large amounts of detail. My initial smoke tests are promising as the SVG files I am using are rendered correctly however performance is poor without any sophisticated drawing optimizations. I believe this is due to the usage of Canvas.drawPicture (svg-android translates the SVG document structure into a single Picture), preventing hardware acceleration on supporting devices and possibly being implemented without efficient trimming of areas outside the clip bounds. Before I begin significant or fundamental optimization however, I'd like to confirm a few things about Android's rendering pipeline (both recent and older versions). Hopefully this will allow me to utilize existing research already conducted by the Android team or other community developers. Specifically:
1. What performance gotchas may exist with simply constructing my own macro notion of a Picture and replaying the raw Canvas operations on draw? That is, define a very simple op-code interpreted language in which I can represent a Picture and simply "execute" it on draw myself much like how I assume Picture is natively implemented. Will this alone be sufficient to permit hardware acceleration? I'm assuming no given that Android developers would have implemented drawPicture on the hardware accelerated path if it were this simple, but I'd like to understand why and if there may be anything I can do to mitigate the issues in my specific case. 2. I believe an asynchronous tiling bitmap layer may be an appropriate solution where sections of the SVG are dynamically rendered to off- screen bitmaps and blitted on screen. A separate renderer thread would be used to manage writing to a cache of off-screen bitmaps. Can hardware acceleration help in some way with this off-screen rendering or would it merely kick in with improved performance when blitting those tiles to screen? If no, I may be able to avoid the issues with #1 entirely since hardware acceleration wasn't going to speed up the off-screen rendering anyway. 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? Can I expect that it behaves consistently when drawing a Picture versus drawing a Path? This is especially important if I implement a tiling renderer as per #2 where a large number of draw requests will be made for the full graphic to render into discrete sections. If Canvas cannot reasonably minimize cycles for this case I will likely need to implement my own culling optimizations. If anyone has other suggestions for things I didn't consider please feel free to let me know. 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
