B2G desktop doesn't redraw the UI properly

RESOLVED FIXED in Firefox 18

Status

()

Core
Graphics: Layers
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: squib, Assigned: cjones)

Tracking

unspecified
mozilla20
x86_64
Linux
Points:
---

Firefox Tracking Flags

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

Details

(Whiteboard: b2g-desktop-builds)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

5 years ago
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.
blocking-basecamp: --- → ?
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

Updated

5 years ago
Assignee: nobody → bugs
This seems to affect enough people and impede progress on B2G that we think it warrants investigation.
Assignee: bugs → nobody
blocking-basecamp: ? → +
Created attachment 670448 [details] [diff] [review]
Workaround

I ran into this yesterday when trying to test something else.  This workaround is nowhere near landable, but stanches the bleeding.
Created attachment 670611 [details] [diff] [review]
Only bother computing an invalid rect if it affects composition
Assignee: nobody → jones.chris.g
Attachment #670448 - Attachment is obsolete: true
Attachment #670611 - Flags: review?(matt.woodrow)
Component: General → Graphics: Layers
Product: Boot2Gecko → Core
Comment on attachment 670611 [details] [diff] [review]
Only bother computing an invalid rect if it affects composition

Has problems.
Attachment #670611 - Flags: review?(matt.woodrow)
Comment on attachment 670448 [details] [diff] [review]
Workaround

More functional bandaid.
Attachment #670448 - Attachment is obsolete: false
Attachment #670611 - Attachment is obsolete: true
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.
Whiteboard: b2g-desktop-builds
Duplicate of this bug: 810765
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.
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?
Created attachment 681436 [details] [diff] [review]
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.
Attachment #670448 - Attachment is obsolete: true
Attachment #681436 - Flags: review+
https://tbpl.mozilla.org/?tree=Try&rev=25e432d92cb8
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 tested Staś build, it works greatly
http://people.mozilla.com/~stas/b2g/
(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.
(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 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.
Attachment #681436 - Flags: review+ → review-
Created attachment 682965 [details] [diff] [review]
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.
Attachment #681436 - Attachment is obsolete: true
Attachment #682965 - Flags: review?(matt.woodrow)
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().
Attachment #682965 - Flags: review?(matt.woodrow) → review+
(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?
https://tbpl.mozilla.org/?tree=Try&rev=8fa51bb2b3b5
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.
Oh, it might not have been clear but all this work has been with GL layers on gtk2.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b3cd0b7de627

... and he hangs his head in shame.
https://hg.mozilla.org/mozilla-central/rev/b3cd0b7de627
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Duplicate of this bug: 783076
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?
It's certainly possible that there are other bugs here.  Please file a followup with the specific symptoms you're seeing.
https://hg.mozilla.org/releases/mozilla-aurora/rev/4aa8acd0d44c
status-firefox19: --- → fixed
https://hg.mozilla.org/releases/mozilla-beta/rev/92c4fe210eb9
status-firefox18: --- → fixed
Blocks: 817278
The fix for this caused bug 817279.

Chris: can you take a look at that bug (or back this out until you can)?
Erm, I meant bug 817278.
No longer blocks: 817278
Depends on: 817278
You need to log in before you can comment on or make changes to this bug.