The default bug view has changed. See this FAQ.

Pre-render overflow area of frames translated by CSS transforms, that are active and partially visible

RESOLVED FIXED in mozilla12



5 years ago
5 years ago


(Reporter: cjones, Assigned: roc)


Dependency tree / graph

Firefox Tracking Flags

(firefox11 wontfix)



(2 attachments, 1 obsolete attachment)

For the "gaia" user interface of b2g (demo, we have a lock screen that's simply a <div> moved around by a CSS transform (translation).  It's the "sunset" screen in the demo.  The CSS transform isn't animated by CSS animations, but rather the translation is just adjusted by script based on input events.

On device, the lock screen is ridiculously slow with GL enabled, probably somewhere around 3-5 fps.  With GL off, it's better but still slow.  Based on evidence from previous bugs, I'm guessing this is a combination of three factors
 (1) sizing the backing buffer to the <div>'s actual visible region.  This means that as it's moved into place, it slowly grows, forcing a realloc on each resize.
 (2) related to (1), having to continuously repaint because of the buffer realloc.
 (3) slowness when uploading to textures

(3) is orthogonal to layout/layers issues, but since the perf with GL disabled is noticeably better, I'm guessing that that's what's dominating this testcase.  However, fixing (1) and (2) is still worthwhile, in particular because it's a necessary condition for async CSS animations.

To fix (1) and (2) for this test, I think all we need to do is the following
 - when we're building a layer for a DisplayTransform (which implies that the underlying frame is visible)
   - if the transform is a translation
     - if the computed size of the underlying frame is within some bound (screen size would suffice for this testcase; probably want to make a make a bound on number of pixels instead of dimensions.  Maybe maxPixels = screenWidth * screenHeight * 2?)
       - create a layer for the transformed frame with a "fudged" visible region for its computed size
       - paint the layer into that fudged visible region

With this special case, as long as the transformed frame was visible and active, it would never be repainted.  This would have the side effect of "working around" the texture-uploading problem we're seeing with EGL.

When animated transforms are involved, there's much more cool stuff we can do, but that's work for another bug ...
FTR: in a build off of latest m-c, which has some texture-upload improvements, my test is indeed noticeably faster.  But still not fast enough! ;)


5 years ago
Blocks: 706179
Focusing this bug for better action.

There are several simple animations in the b2g UI ("gaia") for which the framerate is too low.  All but one of them are simple animated translations.  I'm 99% sure this bug will significantly improve the perf there.  If that's the case for gaia, I suspect this might be true of general web content too.

Is there anyone on the layout or gfx teams who can up this bug?
Summary: Add some special cases for CSS transforms in layer builder → Pre-render overflow area of frames translated by CSS transforms, that are active and partially visible
* who can *pick* up this bug

I should also add that the other simple animation is an animated scale+transform, which can be optimized similarly to translation-only but is slightly more complicated.
Bug 524925 would probably help with your issues too.
Created attachment 581567 [details] [diff] [review]

Something like this might work.
Created attachment 581845 [details] [diff] [review]
Don't dirty the transformed frame when we reflow it due to a transform change
Assignee: nobody → roc
Attachment #581845 - Flags: review?(matspal)
The above patch is needed to make the tests in the next patch pass. It avoids having to reflow the children of the transformed frame when the transform changes, and avoids invalidations triggered by those reflows. It's simple and should be safe.

Bug 524925 is much better and obsoletes the above patch. But we should take the above patch anyway.
Created attachment 581848 [details] [diff] [review]
prerendering fix

This is very simple actually. The heuristic in nsDisplayTransform::ShouldPrerenderTransformedContent might need to be tweaked later but it should be good enough for now.
Attachment #581567 - Attachment is obsolete: true
Attachment #581848 - Flags: review?(matspal)
Is this needed before Dec 20?  if so, and if bug 524925 fixes this issue completely
and better, how would you feel about taking that instead (without bug 665597)?
(In reply to Mats Palmgren [:mats] from comment #9)
> Is this needed before Dec 20?

I don't know. The patch is small, I think we could take it before the branch.

> if so, and if bug 524925 fixes this issue
> completely and better, how would you feel about taking that instead (without bug
> 665597)?

Bug 524925 only obsoletes part 1, which is itself a very small and safe patch. I think we should just take part 1 before the branch and land 524925 after the branch.

Plus, bug 524925 does need bug 665597. See


5 years ago
Attachment #581848 - Flags: review?(matspal) → review+


5 years ago
Attachment #581845 - Flags: review?(matspal) → review+
Thanks roc!  We'll test this in b2g asap.
Is this ready for checkin-needed?
Whiteboard: [inbound]
Backed out on inbound (along with other patches in the same push) because of Mac and Win7 reftest failures:
Whiteboard: [inbound]
This didn't cause the failures.
Whiteboard: [inbound]
(In reply to Chris Jones [:cjones] [:warhammer] from comment #11)
> Thanks roc!  We'll test this in b2g asap.

These don't seem to be kicking in where they should in b2g, but all those frames using transitions or animations, so there may be a bad interaction there.  Will file a followup.
You can set a breakpoint in nsDisplayTransform::ComputeVisibility to see if the prerendering path is kicking in.
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla11


5 years ago
Depends on: 717521


5 years ago
Resolution: FIXED → ---
The backout was only for Fx11, so I think we can resolve this as Fixed again, but
with milestone:mozilla12 and status-firefox11:wontfix -- does that sound right?
Yes, I think so.
Last Resolved: 5 years ago5 years ago
status-firefox11: --- → wontfix
Resolution: --- → FIXED
Target Milestone: mozilla11 → mozilla12
You need to log in before you can comment on or make changes to this bug.