Closed Bug 1165667 Opened 7 years ago Closed 6 years ago

Excessive delay on call to clientwidth, with CSS Flexbox & Direct2D

Categories

(Core :: Layout, defect)

38 Branch
Unspecified
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed

People

(Reporter: mahks1, Assigned: dholbert)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached file clientWidth.php
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150513174244

Steps to reproduce:

Change the width of a div containing many flex nodes.
Then, any access of clientWidth on the parent will cause a delay.


Actual results:

My app was very sluggish, it uses CSS flex a lot.
When I tried to find the cause, I found it was due to resizing & my use of clientWidth. 

While the following durations are not long, when the behaviour is multiplied many times, it becomes a problem.

FF 37.0.2	: 600 ~ 700ms
FF 38 : 400 ~ 900 ms
FF Nightly 41.0a1 : 400 ~ 900 ms


Expected results:

Chrome 43 beta : 85 ~ 100ms
Chrome 42 : 180 ~ 200ms
You can access the test case here : http://www.starlords3k.com/tests/clientWidth.php
Component: Untriaged → DOM
Product: Firefox → Core
Component: DOM → Layout
On the testcase in comment 1, in a current nightly, I get times around 30ms.  Chrome dev on the same machine gets times around 30ms as well.

I do see 60-90ms in Firefox 37, and and 30-50ms in Firefox 38.  But nothing even lose to the times listed in comment 0....
https://hg.mozilla.org/mozilla-central/rev/4fb7ff694bf5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 ID:20150519030202

Enable HWA
~500ms

Enable HWA, but gfx.content.azure.backends = cairo
~100ms

Disable HWA
~100ms


IE11
~800ms


Chrome Dev44
~100ms


So, Direct2d(Direct2d1.1) is slow than cairo.
OS: Unspecified → Windows
Status: UNCONFIRMED → NEW
Ever confirmed: true
Gecko Profiler shows we're spending a lot of time in gfxContext::Release, most of which is in DrawTargetD2D1::Flush.

This is with the reference rendering context we create in ResolveAutoFlexBasisAndMinSize, for a call to GetMinISize.

It surprises me that reference rendering contexts are so expensive to tear down. It looks like I probably don't need to be creating/destroying a rendering context here, though -- this is inside of reflow, and the reflow state has a rendering context (.rendContext) which is really what I should be using.
Assignee: nobody → dholbert
Flags: needinfo?(dholbert)
Ah, interesting.  The comment 2 times were on Mac.
(I saw similar times to those described in comment 2 on Linux, FWIW.)
Summary: Excessive delay on call to clientwidth → Excessive delay on call to clientwidth, with CSS Flexbox & Direct2D
Attached patch fix v1Splinter Review
Flags: needinfo?(dholbert)
Attachment #8608239 - Flags: review?(mats)
(If it's not clear, I'm only introducing the local variable 'frameMinISize' as a way of saving on line-length / awkward-wrapping.)
Comment on attachment 8608239 [details] [diff] [review]
fix v1

r=mats
Attachment #8608239 - Flags: review?(mats) → review+
Flags: in-testsuite-
https://hg.mozilla.org/mozilla-central/rev/a33ee01bca86
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.