When requestRenderFrame? about openlayers HOT 6 CLOSED

With this sequence:

requestRenderFrame();
withFrozenRendering(function() {
  setCenter();
  setResolution();
});

withFrozenRendering will fire the rendering. This is definitely is a bug in withFrozenRendering (unfreezeRendering actually).

We could consider that it's stupid to use both requestRenderFrame and withFrozenRendering (as the above example), because withFrozenRendering is useless if requestRenderFrame was called. But, the problem is that we have different players here:

• View2D.zoom calls both setCenter and setResolution, so it makes sense for it to use withFrozenRendering,
• DragRotateAndZoom.handleDrag handles drag events, so it makes sense for it to use requestRenderFrame.

This really suggests fixing withFrozenRendering (and adding unit tests to test that logic).

Bruno, and I just talked about requestRenderFrame and withFrozenRendering.

We agree that calling requestRenderFrame multiple times is not a problem (a bug, I should say), but we also agree that we need to clean up our mess.

We also think that it's a good thing to have both requestRenderFrame and withFrozenRendering. It really separates the concepts. withFrozenRendering enables grouping changes without triggering rendering, while requestRenderFrame requests an animation frame.

To answer Tim's question: requestAnimationFrame is to be used when animating, and in interaction to debounce events (mousemove/touchmove events in the case of our drag interactions). Outside these use cases there probably is no reason to use it. Please tell me this is a too weak justification :)

from openlayers.

+1 to @elemoine and @bbinet's analysis.

unfreezeRendering triggering a render after requestRenderFrame has been called is definitely a bug.

To the final paragraph:

To answer Tim's question: requestAnimationFrame is to be used when animating, and in interaction to debounce events (mousemove/touchmove events in the case of our drag interactions). Outside these use cases there probably is no reason to use it. Please tell me this is a too weak justification :)

I'd add that animation is also needed in these cases:

• animating tile fade-in in the Canvas and WebGL renderers (not yet implemented)
• reducing the work done while tiles are loading
• reducing the work done while textures are being uploaded to the GPU

Note that when tiles are loading, we'll need the animation to fade in the tiles anyway, so it makes sense to go into animating mode while tiles are loading rather than responding to image load events.

from openlayers.

I'd add that animation is also needed in these cases:

• animating tile fade-in in the Canvas and WebGL renderers (not yet implemented)
• reducing the work done while tiles are loading
• reducing the work done while textures are being uploaded to the GPU

I was referring to requestAnimationFrame, not animations per-se. Anyway.

from openlayers.

We have a small problem currently (which I already mentioned in some other comment): the interactions and the view "freeze" and/or request a render frame only for the map the user is interacting with. The view should really not call map functions – the view does not have a map, and there may be multiple maps listening to view property changes. What Tim has in mind would fix that. A while back Tom and I briefly mentioned relying on view hints to fix. I'm even wondering if the current view hints (animating and dragging) would not suffice. I want to give it a try, so more on that next week. In the mean time feedback is welcome.

from openlayers.

I have been experimenting with this in my raf branch. https://github.com/elemoine/ol3/compare/openlayers:master...raf. I'm not too happy with it, and need to think more about the issue.

from openlayers.

Closed with #1732..

from openlayers.