Closed Bug 584173 Opened 10 years ago Closed 10 months ago
Content area "flickers" when its panned under the awesomebar
Crossposting a new bug from https://bugzilla.mozilla.org/show_bug.cgi?id=579349#c21. There is still flickering happening when you manage to grab the content area and scroll it under the awesomebar. Repro'd on n900: Mozilla/5.0 (X11; Linux armv7l; rv:2.0b3pre) Gecko/20100803 Namoroka/4.0b3pre Fennec/2.0a1pre Repro: 1) install fennec nightly trunk 20100803 build 2) visit any url page (eg. about:fennec) 3) click and hold the content area down, then slowly pan up so it slides under the awesomebar overlay. You may need to try this a few times, but eventually you'll see the content window move, but not the awesomebar 4) once you get that to stick, pan down slowly far enough that the top of the content area is almost underlay'd behind the awesomebar. Verify it begins flickering. Expected: - no content flicker behind the awesomebar actual: - flicker madness
There should be double-buffering going on here. Someone needs to poke around in BasicLayerManager::EndTransaction to see if useDoubleBuffering is set.
I did check the double-buffering in BasicLayerManager::EndTransaction : - mDoubleBuffering is always true - when we flicker, useDoubleBuffering is false
When doing a test run with useDoubleBuffering forced to true, this particular bug is fixed. This means that MayHaveOverlappingOrTransparentLayers() is not doing what we want in this case.
Yes. Can you figure that out?
Dumping the layer tree and pasting the results here would help.
Here's a layer dump : BasicLayerManager (0xb285b0c0) BasicContainerLayer (0xafadb7c0) [visible=< (x=0, y=0, w=800, h=500); >] [opaqueContent] BasicThebesLayer (0xb05f78b0) [clip=(x=0, y=0, w=0, h=0)] [opaqueContent] BasicColorLayer (0xac6291b0) [clip=(x=0, y=0, w=0, h=0)] [opaqueContent] [color=rgba(0, 0, 0, 0)] BasicThebesLayer (0xac02c480) [visible=< (x=0, y=72, w=147, h=428); >] [opaqueContent] [valid=< (x=0, y=72, w=145, h=428); >] BasicCanvasLayer (0xad66d2e0) [clip=(x=0, y=0, w=800, h=500)] [transform=[ 1 0; 0 1; 20 80; ]] [visible=< (x=0, y=0, w=106, h=64); >] [opaqueContent] BasicCanvasLayer (0xad66de40) [clip=(x=147, y=0, w=653, h=500)] [transform=[ 1 0; 0 1; 147 -17; ]] [visible=< (x=0, y=89, w=512, h=423); >] [opaqueContent] BasicCanvasLayer (0xad66df20) [clip=(x=147, y=0, w=653, h=500)] [transform=[ 1 0; 0 1; 659 -17; ]] [visible=< (x=0, y=89, w=141, h=423); >] [opaqueContent] BasicCanvasLayer (0xad66d740) [clip=(x=147, y=0, w=653, h=500)] [transform=[ 1 0; 0 1; 147 495; ]] [visible=< (x=0, y=0, w=512, h=5); >] [opaqueContent] BasicCanvasLayer (0xad66d9e0) [clip=(x=147, y=0, w=653, h=500)] [transform=[ 1 0; 0 1; 659 495; ]] [visible=< (x=0, y=0, w=141, h=5); >] [opaqueContent] BasicThebesLayer (0xac02c590) [visible=< (x=0, y=0, w=800, h=72); >] [opaqueContent] These are all opaque layers, so there should be some overlapping going on
I think the problem is that MayHaveOverlappingOrTransparentLayers assumes the rendering of each layer will be clipped to its GetVisibleRegion(), but BasicCanvasLayer doesn't do that, it just draws its entire bounds. Even BasicThebesLayer::Paint doesn't do that in the non-retained case, although in the retained case it does clip to exactly the GetVisibleRegion(). The right solution here might be for all the BasicLayer types to have their rendering clipped to their visible region.
I believe this is still there, but with our move away from tiles and to browsers, it is longer happening. Removing blocking flag for fennec
tracking-fennec: 2.0b1+ → ---
(I thought I already added a comment about this) I tried some time ago to come up with a standalone testcase that showed the issue, but I haven't been able to. I even tried it basically with the whole Fennec UI, but still no luck. Now we're in the situation that a standalone testcase would have been very useful, since the issue can't be seen in Fennec itself anymore.
Might be possible to test by putting a -moz-transform on a canvas (/me waves hands).
Assignee: roc → nobody
Closing all opened bug in a graveyard component
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.