One alternative would be to use OpenGL in 2D. There are a lot more examples out there of what you're trying to do, plus it could potentially run on other platforms...
On May 27, 12:51 am, Josh Guilfoyle <[email protected]> wrote: > 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 [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
