799768 - B2G desktop doesn't redraw the UI properly

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Jim Porter (:squib)]

I'm using the latest m-c B2G desktop nightly on Linux64 (under a VM, though Fabrice has reported the same issue on a real machine). After a few seconds, the display in the B2G desktop window refuses to update unless I click on it or move the window around.

I've tried this with layers.acceleration.disabled set to true and false, and both exhibit the same problem.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Another preference to play with is: layers.acceleration.force-enabled

However, my most recent self-built mozilla-central b2g-desktop is painting okay without any of those preferences.  This is Ubuntu 12.04 on a Thinkpad using the Intel graphics.  The about:support graphics setting of a current Firefox nightly for me, which may provide more useful details is:

        Adapter Description
        Tungsten Graphics, Inc -- Mesa DRI Intel(R) Sandybridge Mobile

        Device ID
        Mesa DRI Intel(R) Sandybridge Mobile

        Driver Version
        3.0 Mesa 8.0.2

        GPU Accelerated Windows
        0/1 Basic no information

        Vendor ID
        Tungsten Graphics, Inc

        WebGL Renderer
        no information

        AzureCanvasBackend
        cairo

        AzureContentBackend
        none

        AzureFallbackCanvasBackend
        none

Comment 2

[Andrew Overholt [:overholt]]

This seems to affect enough people and impede progress on B2G that we think it warrants investigation.

Comment 3

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

Attachment: Workaround

I ran into this yesterday when trying to test something else.  This workaround is nowhere near landable, but stanches the bleeding.

Comment 4

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

Attachment: Only bother computing an invalid rect if it affects composition

Comment 5

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

Comment on attachment 670611 [details] [diff] [review]
Only bother computing an invalid rect if it affects composition

Has problems.

Comment 6

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

Comment on attachment 670448 [details] [diff] [review]
Workaround

More functional bandaid.

Comment 7

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

It's been very hard to find time to work on this, but I still a little bit just now.  What's happening is, we have shadow-tree updates and display-list building working fine for the first remote iframe (homescreen).  When I open the second one, we get shadow-tree just fine, but for some reason never ask the RenderFrameParent to BuildLayer().  Not quite sure what's up there yet.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

I'm now seeing this problem on my custom Windows builds of both central and aurora, and the workaround patch doesn't seem to make a difference there.

But another workaround that does work on both Windows and Linux is to disable OOP by setting the debug.oop.disabled setting to true.

Comment 10

[Staś Małolepszy :stas]

On my Linux machine the workaround patch does work and setting debug.oop.disabled setting to true doesn't help at all.  Maybe there are two separate issues that we're dealing with here?

Comment 11

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

Attachment: Only bother computing an invalid rect if it affects composition, restored

This is the same patch as before, but now it works like a charm.  Carrying forward r=mattwoodrow.  Sigh.

Comment 12

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

https://tbpl.mozilla.org/?tree=Try&rev=25e432d92cb8

Comment 13

[Matt Woodrow (:mattwoodrow)]

The first && should be an || surely? On BasicLayers (non-omtc) we *always* need the invalid rect, and on systems with accelerated compositing we need it if there's a MozAfterPaint listener.

Comment 14

[Fernando Pereira Silveira]

I tested Staś build, it works greatly
http://people.mozilla.com/~stas/b2g/

Comment 15

[Staś Małolepszy :stas]

(In reply to Fernando Pereira Silveira from comment #14)
> I tested Staś build, it works greatly
> http://people.mozilla.com/~stas/b2g/

To provide context, I uploaded my custom-compiled builds with attachment 681436 [details] [diff] [review] applied (both 32 and 64 bit) for the localizers to be able to test B2G & Gaia localizations on desktop.

Comment 16

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #13)
> The first && should be an || surely? On BasicLayers (non-omtc) we *always*
> need the invalid rect, and on systems with accelerated compositing we need
> it if there's a MozAfterPaint listener.

I just found myself on a linux system with the redraw problem (ATI FirePro V4800 across 3 monitors on Ubuntu 12.04) and tried making the change you suggest first.  ("!layerManager->IsCompositingCheap() &&" changed to "!layerManager->IsCompositingCheap() ||").  That did not work.  The patch as it exists on the bug seems to work great, however!  (It's also possible you meant to change something in a more clever fashion.)

Comment 17

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

Comment on attachment 681436 [details] [diff] [review]
Only bother computing an invalid rect if it affects composition, restored

I think I too-eagerly set the r+, sorry.  I thought this had gone through a round of review already but I don't see any evidence here.  (Maybe I was thinking of an IRC chat ...)

(In reply to Matt Woodrow (:mattwoodrow) from comment #13)
> The first && should be an || surely? On BasicLayers (non-omtc) we *always*
> need the invalid rect, and on systems with accelerated compositing we need
> it if there's a MozAfterPaint listener.

Interestingly, this patch was happy on tryserver for basic, but not GPU layers.  Let me poke a bit more.

Comment 18

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

Attachment: Only bother computing an invalid rect if it affects composition and enable omtc for X11 b2g builds

The IsCompositingCheap() change doesn't make a difference but is what this should have been using.

Enabling OMTC for X11 is also what we want, and incidentally works around this bug.  That this change works around the bug suggests there's something wrong (or different than OS X) in the gtk2 widget backend when GL is enabled.  Since we need omtc to test all platform features, I'm happy to take the workaround and stick my head in the sand for the gtk2 difference in behavior.

Comment 19

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 682965 [details] [diff] [review]
Only bother computing an invalid rect if it affects composition and enable omtc for X11 b2g builds

Review of attachment 682965 [details] [diff] [review]:
-----------------------------------------------------------------

These changes seem fine but we're definitely dodging a probable bug doing so :)

The fact that the older patch worked suggests that passing the result of props->ComputeDifferences to InvalidateViewNoSuppression is having a different affect to just invalidating the entire view.

I can't think of anything that would be platform specific in ComputeDifferences, and it definitely works on desktop, but it's possible the result is in the wrong coordinate space. Would be easy to check if the rect we compute falls within view->GetDimensions().

Comment 20

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

(In reply to Matt Woodrow (:mattwoodrow) from comment #19)
> Comment on attachment 682965 [details] [diff] [review]
> Only bother computing an invalid rect if it affects composition and enable
> omtc for X11 b2g builds
> 
> Review of attachment 682965 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> These changes seem fine but we're definitely dodging a probable bug doing so
> :)
> 

I agree.

> I can't think of anything that would be platform specific in
> ComputeDifferences, and it definitely works on desktop,

You mean works on OS X?

Comment 21

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

https://tbpl.mozilla.org/?tree=Try&rev=8fa51bb2b3b5

Comment 22

[Matt Woodrow (:mattwoodrow)]

We should be hitting that path anytime we have BasicLayers or a paint listener, so all of linux, reftests on all platforms, OSX with blocker drivers etc.

Comment 23

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

Oh, it might not have been clear but all this work has been with GL layers on gtk2.

Comment 24

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/b3cd0b7de627

... and he hangs his head in shame.

Comment 25

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/b3cd0b7de627

Comment 27

[Andrew Sutherland [:asuth] (he/him)]

My b2g-desktop's painting is basically broken with or without this patch when building from post-uplift mozilla-beta.  And definitely broken with a patched mozilla-aurora.  Should this require a mozilla-central build?

Comment 28

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

It's certainly possible that there are other bugs here.  Please file a followup with the specific symptoms you're seeing.

Comment 29

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/4aa8acd0d44c

Comment 30

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

https://hg.mozilla.org/releases/mozilla-beta/rev/92c4fe210eb9

Comment 31

[Myk Melez [:myk] [@mykmelez]]

The fix for this caused bug 817279.

Chris: can you take a look at that bug (or back this out until you can)?

Comment 32

[Myk Melez [:myk] [@mykmelez]]

Erm, I meant bug 817278.