Closed GoogleCodeExporter closed 9 years ago
Investigating the osm and android sources some more, I think it is likely this
bug happens inside GLES20RecordingCanvas rather than being an osm bug. If that
is the case, I am amazed it has not surfaced earlier.
Original comment by vit.hrad...@gmail.com
on 26 Jul 2013 at 7:13
Thank you for the project. Yes - I have seen this before. If you check LogCat,
you will see:
08-01 22:29:55.583: W/OpenGLRenderer(3672): Path too large to be rendered into
a texture
This is a problem with HW accelerated Paths - they have to be converted into
Bitmaps to be uploaded as textures to OpenGL. If the Path is too big, then the
Bitmap is too big and it fails.
I have seen solutions that create a screen-sized Bitmap and then draw the Path
to that Bitmap and then draw that Bitmap to the Canvas. Another possible
solution is to make a smaller path (say, within some factor of the screen-size)
and then draw that scaled to the canvas - this keeps the Bitmap small and lets
OpenGL scale it to the proper size (with loss of resolution). But as of now,
there is no solution.
I am going to merge this in with our main HW acceleration ticket. Thanks for
the feedback.
Original comment by kurtzm...@gmail.com
on 2 Aug 2013 at 2:34
Merging with our main hardware acceleration ticket.
Original comment by kurtzm...@gmail.com
on 2 Aug 2013 at 2:36
I can workaround this issue by using sofrware rendering configuration.
mapView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
Original comment by duyan...@gmail.com
on 31 Dec 2013 at 3:24
Isn't there a way to detect the issue and switch over to software at run-time?
This is very annoying to have to disable HW acceleration permanently while it
only fails on occasion!
Original comment by androtu...@gmail.com
on 10 Mar 2014 at 1:00
Original issue reported on code.google.com by
vit.hrad...@gmail.com
on 26 Jul 2013 at 6:27Attachments: