The following sequence of events can happen in current Maple: 1. Page is rendered fine at zoom 1.0 2. User rotates device, this calls setViewportSize on the java side and calculates a new zoom factor of 1.6 3. setViewportSize calls notifyLayerOfGeometryChange which queues a resize event in the gecko queue 4. The resize event from step 3 is handled in browser.js. This synchronously sends an UpdateAndDraw event to java, which sets mUpdateViewportOnEndDraw and queues a DRAW event in nsWindow behind the resize event from step 3 5. notifyLayerOfGeometryChange continues executing and queues a Viewport:Change event behind the DRAW event from step 4. setViewportSize finishes 6. the DRAW event from step 4 runs, and paints content at a 1.0 zoom level, and tells java it has painted stuff at 1.0 via beginDrawing/endDrawing. 7. Java clobbers its own viewport with the one from step 6 because of the mUpdateViewportOnEndDraw flag set in step 4. This sets the java zoom factor back to 1.0. 8. The Viewport:Change event from step 5 is handled in browser.js and sets the gecko zoom to 1.6 via setResolution. The handler also triggers an invalidate. 9. The invalidate from step 8 is processed and triggers a new DRAW event. 10. The DRAW event from step 9 is processed and does paints content at zoom 1.6 (which is what is in gecko at this point). 11. beginDrawing/endDrawing runs, which notifies java that content was painted at zoom 1.6 (this is saved into the root layer's mResolution). Note that in the viewport itself, only the page size is updated, so the viewport in LayerController still has a 1.0 zoom factor. 12. Compositor runs and queries java for the zoom to render at; java returns 1.0. 13. Compositor takes the content drawn at 1.6 and scales it down to 1.0. This leaves some blank areas on the screen which are checkerboarded. Also the rendered content is blurry. Final state: - gecko zoom is at 1.6 - java zoom is at 1.0 - content is painted at 1.6 - compositor is scaling 1.6 content down to 1.0 - no more draw events are pending, so unless the user does something, it remains this way Note that if step 5 happens before step 4 (which is entirely possible because they run on different threads) then the first DRAW event that gets processed (in step 6) uses the new zoom level of 1.6 rather than the old zoom level of 1.0 and everything works out ok, with the final state being that everybody has a 1.6 zoom level.
This race condition should be eliminated in the grand new design (as described at https://wiki.mozilla.org/Fennec/NativeUI/Viewport, and being implemented in bugs 732091 and 732564).
Fixed as part of bug 732564, but should be verified independently (STR are basically go to a page and rotate; if there is checkerboard on the screen that doesn't go away then this bug isn't fixed).
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Resolution: FIXED → DUPLICATE
Duplicate of bug: 732564
You need to log in before you can comment on or make changes to this bug.