Last Comment Bug 799768 - B2G desktop doesn't redraw the UI properly
: B2G desktop doesn't redraw the UI properly
Status: RESOLVED FIXED
b2g-desktop-builds
:
Product: Core
Classification: Components
Component: Graphics: Layers (show other bugs)
: unspecified
: x86_64 Linux
: -- normal (vote)
: mozilla20
Assigned To: Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
:
Mentors:
: 783076 810765 (view as bug list)
Depends on: 817278
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-09 16:29 PDT by Jim Porter (:squib)
Modified: 2012-12-05 15:35 PST (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed
fixed


Attachments
Workaround (1.46 KB, patch)
2012-10-11 10:45 PDT, Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
no flags Details | Diff | Splinter Review
Only bother computing an invalid rect if it affects composition (1.51 KB, patch)
2012-10-11 16:56 PDT, Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
no flags Details | Diff | Splinter Review
Only bother computing an invalid rect if it affects composition, restored (1.51 KB, patch)
2012-11-14 03:45 PST, Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
cjones.bugs: review-
Details | Diff | Splinter Review
Only bother computing an invalid rect if it affects composition and enable omtc for X11 b2g builds (2.04 KB, patch)
2012-11-18 18:55 PST, Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
matt.woodrow: review+
Details | Diff | Splinter Review

Description Jim Porter (:squib) 2012-10-09 16:29:14 PDT
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] 2012-10-11 10:32:24 PDT
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] (back Aug 31) 2012-10-11 10:38:18 PDT
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 2012-10-11 10:45:35 PDT
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.
Comment 4 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-11 16:56:26 PDT
Created attachment 670611 [details] [diff] [review]
Only bother computing an invalid rect if it affects composition
Comment 5 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-11 17:08:21 PDT
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 2012-10-18 11:22:55 PDT
Comment on attachment 670448 [details] [diff] [review]
Workaround

More functional bandaid.
Comment 7 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-24 12:47:42 PDT
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 8 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-11-13 05:29:54 PST
*** Bug 810765 has been marked as a duplicate of this bug. ***
Comment 9 Myk Melez [:myk] [@mykmelez] 2012-11-13 13:10:18 PST
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 2012-11-13 18:09:26 PST
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 2012-11-14 03:45:55 PST
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.
Comment 12 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-11-14 03:47:14 PST
https://tbpl.mozilla.org/?tree=Try&rev=25e432d92cb8
Comment 13 Matt Woodrow (:mattwoodrow) 2012-11-14 09:53:19 PST
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 2012-11-14 11:11:25 PST
I tested Staś build, it works greatly
http://people.mozilla.com/~stas/b2g/
Comment 15 Staś Małolepszy :stas 2012-11-14 15:06:32 PST
(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] 2012-11-17 19:47:14 PST
(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 2012-11-18 13:11:18 PST
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 2012-11-18 18:55:30 PST
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.
Comment 19 Matt Woodrow (:mattwoodrow) 2012-11-18 19:17:44 PST
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 2012-11-19 11:05:35 PST
(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 2012-11-19 11:05:52 PST
https://tbpl.mozilla.org/?tree=Try&rev=8fa51bb2b3b5
Comment 22 Matt Woodrow (:mattwoodrow) 2012-11-19 15:06:47 PST
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 2012-11-19 15:09:32 PST
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 2012-11-19 23:28:37 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/b3cd0b7de627

... and he hangs his head in shame.
Comment 25 Ed Morley [:emorley] 2012-11-20 07:04:10 PST
https://hg.mozilla.org/mozilla-central/rev/b3cd0b7de627
Comment 26 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-11-20 10:31:37 PST
*** Bug 783076 has been marked as a duplicate of this bug. ***
Comment 27 Andrew Sutherland [:asuth] 2012-11-21 01:39:55 PST
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 2012-11-21 15:24:01 PST
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 2012-11-21 17:14:41 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/4aa8acd0d44c
Comment 30 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-11-21 17:35:56 PST
https://hg.mozilla.org/releases/mozilla-beta/rev/92c4fe210eb9
Comment 31 Myk Melez [:myk] [@mykmelez] 2012-12-05 14:49:34 PST
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] 2012-12-05 14:50:34 PST
Erm, I meant bug 817278.

Note You need to log in before you can comment on or make changes to this bug.