Closed Bug 915872 Opened 9 years ago Closed 8 years ago
Homescreen doesn't render background layer when APZC is turned on
+++ This bug was initially created as a clone of Bug #909887 +++ When the patch from bug 909877 is applied to turn on APZC everywhere, the homescreen background layers don't seem to render properly. Copied from https://bugzilla.mozilla.org/show_bug.cgi?id=909887#c13: If you pan the homescreen the background appears while panning but then disappears again. If you don't apply the patch from bug 909881 then zooming the homescreen seems to permanently fix the background, even if you zoom back out to the original zoom level. Brad was saying that he saw a similar background-not-painting issue with the tiling patches applied so I suspect that it's somewhere deep in gfx code.
So turning off APZC in the homescreen app makes this problem go away. Which is kind of odd because I thought the background was drawn by the system app, but there you have it.
This applies on top of the patch in bug 909877 and disables it for the homescreen app.
fwiw we are thinking of moving some of the background code directly into the homescreen app in the future. See bug 900551
blocking-b2g: --- → 1.3+
By the way, the right fix for this is to come up with a way to express snapping in CSS and then make the entire homescreen one really wide frame. We let the scroll mechanics than pre-render a viewport slightly larger than the currently visible plane and we no longer have to pre-render the entire frame to the left and right. Its enough if a few tiles are there so we can start panning and render the rest of the area on the fly.
How far is the CSS snapping property? If it's far we can simulate it by having main thread JS push a transaction to the APZC. We're on our way to having the homescreen pan smoothly on the main thread so we should be able to rely on the main thread for pushing a transaction to force the snap with a transition once we switch the homescreen to use APZC.
I don't think we have made any progress on CSS snapping. I have no idea what you mean, but it sounds good. Switching the HS to APZC would be pretty impressive. Same for gallery.
The CSS snapping property sounds like -ms-scroll-snap-points-x . If we're interested in implementing that we should probably get the ball rolling on the standardization front for that as well. The Fennec team was also interested in having behaviour like that to play around with. I'm not sure how related this actually is to this bug, though. If we're interested in CSS snapping then we should do that in a separate bug.  http://msdn.microsoft.com/en-us/library/windows/apps/hh466031.aspx
(In reply to Andreas Gal :gal from comment #4) > By the way, the right fix for this is to come up with a way to express > snapping in CSS and then make the entire homescreen one really wide frame. > We let the scroll mechanics than pre-render a viewport slightly larger than > the currently visible plane and we no longer have to pre-render the entire > frame to the left and right. Its enough if a few tiles are there so we can > start panning and render the rest of the area on the fly. Yep we discussed that during the last layout/gfx work week in Paris. They told us it will be doable in the future for Gallery. We also want to use it for the edge gesture stuff. Also now that the homescreen background lives into the homescreen app, does this bug is still blocking us to enable APZC? I feel like I don't see the issue anymore?
I am also not seeing this any more. Closing WFM.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #7) > I'm not sure how related this actually is to this bug, though. If we're > interested in CSS snapping then we should do that in a separate bug. For reference, CSS snapping is bug 945584.
No longer blocks: gaia-apzc-2
You need to log in before you can comment on or make changes to this bug.