Fix zero opacity case

[pearcetm]

This fix checks a TiledImage for the case that opacity === 0 and where _preload is false and aborts the tile updates if so, which stops tiles from being loaded for a fully transparent layer. Will fix the undesirable behavior described in #2461

[jetic83]

This does not seem to address the issue in #2461 . Rather, the opacity condition should be in tiledimage.js:294 update function.

[pearcetm]

@jetic83 Try the latest. It is now working correctly for me in my tests.

I moved the logic for checking for the zero opacity case (in conjunction with the preload option) into getDrawArea which makes it work well. I believe doing it this way will still allow any relevant events to fire about the springs updating, etc., even while the image is zero opacity (which is desirable).

[jetic83]

Hi @pearcetm , yes, this works for me as well, thanks!
There seems to be a minor unnecessary change in test/demo/drawercomparison.js, but otherwise, I am fine with the commit as a solution.

[pearcetm]

Great, glad you could confirm it works for you. The minor change in the demo page was just due to some tweaks I made to test this (before I realized I didn't need to change it after all).

The most recent commit also lets the new WebGLDrawer skip the entire drawing pipeline for zero-opacity images, which should help performance in the case where potentially hundreds or more TiledImages are loaded but are fully transparent. Finally, the CanvasDrawer and HTMLDrawer had logic related to the _preload status of the TiledImage which isn't needed and would be counterproductive from a performance status. Those have been fixed as well.

Thank you for pointing this out so we can get it fixed!

[iangilman]

Awesome!