When zoomed in and then repeatedly zooming in and out while panning at the same time, I'm seeing a mix of content at different zoom levels, and incorrect colours (e.g. red becoming blue). This is happening both on a Nexus S and on a Galaxy Tab. The amount of zooming and panning needed to see these problems varies, even on the same page -- sometimes it's right away, and other times it requires a bit longer (no more than a minute though). This is a regression. Range: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=58c9046d8485&tochange=a5b88a4500aa
This looks like readback from front to back buffers is being messed up.
Created attachment 566922 [details] [diff] [review] Disable lazy backBuffer creation until rootcause fixed. Ok, problem here is that PaintThebes, BasicThebesBuffer::BeginPaint assume that all buffer operations are finished and buffer is the all the time same (no double-buffering)... and calling SyncBackAndFront just in the beginning of PaintThebes not enough.. I need to think more about fixing that problem with ThebesLayerBuffer, will try to find better place for SyncBackAndFront... Here is minor fix which does not revert whole Thebes Swap rework, but just making Buffers in sync right after Swap.
Created attachment 566927 [details] [diff] [review] Disable lazy backBuffer sync for SingleBuffer mode
Comment on attachment 566927 [details] [diff] [review] Disable lazy backBuffer sync for SingleBuffer mode This fixes the corruption caused by panning/zooming, but not the colour problem. Please change the commit message to say what the patch does. Also, when this lands, we should keep the bug open while we find the real cause (and deal with the colour issue).
Attachment #566927 - Flags: review?(ajuma) → review+
Ok, I found what is the problem with thebes layers... with static front we had front destroyed when backBuffer content type changed... but now we only do that when size is changed... BackingSurface with locking handle it because we handle properly composition form surface to texture with different format types... but GLContext::UploadSurfaceToTexture cannot do that... (another bug?)
Created attachment 566965 [details] [diff] [review] Fixed color problem Ok, ehre is fix for color problem, we should check if new surface and current texture have equal format
(In reply to Oleg Romashin (:romaxa) from comment #9) > Created attachment 566965 [details] [diff] [review] [diff] [details] [review] > Fixed color problem This patch does indeed fix both problems for me.
Status: ASSIGNED → NEW
Attachment #566965 - Flags: review?(ajuma) → review+
Attachment #566965 - Flags: review?(jones.chris.g) → review+
In my queue with a few other bits that are being sent to try first and then onto inbound :-) https://tbpl.mozilla.org/?tree=Try&rev=488d4a5f274a
Target Milestone: --- → mozilla10
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.