584173 - Content area "flickers" when its panned under the awesomebar

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Tony Chung [:tchung]]

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

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There should be double-buffering going on here. Someone needs to poke around in BasicLayerManager::EndTransaction to see if useDoubleBuffering is set.

Comment 2

[[:fabrice] Fabrice Desré]

I did check the double-buffering in BasicLayerManager::EndTransaction :
- mDoubleBuffering is always true
- when we flicker, useDoubleBuffering is false

Comment 3

[[:fabrice] Fabrice Desré]

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.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes. Can you figure that out?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Dumping the layer tree and pasting the results here would help.

Comment 6

[[:fabrice] Fabrice Desré]

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

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 8

[Stuart Parmenter]

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

Comment 9

[Martijn Wargers (dead)]

(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.

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Might be possible to test by putting a -moz-transform on a canvas (/me waves hands).

Comment 11

[BMO Automation]

Closing all opened bug in a graveyard component