Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for hardware acceleration #52

Open
GoogleCodeExporter opened this issue Dec 8, 2015 · 0 comments
Open

Support for hardware acceleration #52

GoogleCodeExporter opened this issue Dec 8, 2015 · 0 comments

Comments

@GoogleCodeExporter
Copy link

I know that, as explained in your FAQ, when displaying an SVG using an 
(SVG)ImageView, or using something else that requires a Picture or 
(Picture)Drawable, it is probably always going to be necessary to disable HWA 
because rendering would always(?) involve a call to Canvas#drawPicture() -- 
which will likely never be supported on a hardware-accelerated canvas.

However, when rendering an SVG straight to a Canvas using SVG#renderToCanvas(), 
I think we may actually be able to increase performance by allowing for HWA. If 
I'm not mistaken this would require that SVGAndroidRenderer does not call any 
drawing methods on either Canvas or Paint which are unsupported when HWA is 
enabled.
So have you perhaps already been trying to (completely?) avoid calling such 
methods? And if not, do you think it would be possible at all?
Note this may also require some Canvas.isHardwareAccelerated() checks to 
trigger alternative rending strategies.
Also note that the list of HWA-supported drawing methods has been growing with 
each new Android release 
(http://developer.android.com/guide/topics/graphics/hardware-accel.html#unsuppor
ted), so complete avoidance would perhaps only be possible on recent Android 
releases.

If such HWA support is possible it would perhaps also make sense to provide an 
additional (Image)View subclass which does not rely on SVG#renderToPicture() 
but instead uses SVG#renderToCanvas() and does not force HWA to be disabled.

Original issue reported on code.google.com by matthias...@gmail.com on 27 Jan 2015 at 9:02

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant