Efficiency: Vector layer example crashes on Android #764

szymonc opened this Issue Jun 4, 2013 · 6 comments


None yet

3 participants

szymonc commented Jun 4, 2013

The problem is related not only to the vector example. Any example with more than one layer or any overlays will most likely crash in about ~10 sec. extensive of use - zooming in/out, scrolling, rotating. Using it carefully is possible though it's a very painful experience.

I'm making the tests with the Chrome browser. I have also tried the PhoneGap app with my own app that has some short route on the vector layer. It's also crushing.
Trying it on iPad2 brings moreover the same effect.

Cheers and thanks for your effort!

twpayne commented Jun 5, 2013

Thanks for the bug report. Which Android device and browser are you using?

szymonc commented Jun 5, 2013

B&N Nook Tablet
Android : 4.1.2
CyanogenMod: 10
Chrome: 25

PS. In the PhoneGap it was running out of memory very fast and that was the reason of the crash. So the crash it in the browser would be for the similar reason I guess.

twpayne commented Jun 6, 2013

We discussed this at today's hangout, and identified some options for improving performance:

  • The way that interim tiles are currently rendered is not fast. Consider a 2x2 tile map in which one tile is missing. Currently the interim tile is drawn first, which invalidates 2x2 = 4 tiles, so the three available tiles must be redrawn. Better tracking of which pixels need updating as tiles load will alleviate this problem.
  • Interim tiles can be disabled for all but the lowest layer and/or when interacting with the map or animating.
  • We can monitor the actual frame rate and disable interim tiles and/or not draw layers if it drops too low while interacting/animating.
  • Layer composition is currently specific to each renderer. For example, the DOM renderer uses a number of overlapping DIVs, the Canvas renderer composes all layers into a single Canvas using drawImage, and the WebGL renderer composes multiple layers in separate framebuffers into a single Canvas using WebGL calls. It is possible that different strategies might perform better. For example, it may be better for the Canvas renderer to render each layer into a separate canvas and then let the browser do the compositing.
  • Layers with many transparent pixels are currently inefficient. This is because every layer is treated as a raster layer and every pixel is composited. Only drawing pixels that are known to be non-transparent would be a huge win. See "Remember Not To Waste Your Memory" for more details.
elemoine commented Jun 6, 2013

Good summary Tom. Thanks a lot!

twpayne commented Jan 20, 2014

@szymonc, can you re-test this with the latest master?

twpayne commented Mar 17, 2014

Closing due to lack of response.

@twpayne twpayne closed this Mar 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment