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

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Mahks]

Attachment: 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

Comment 1

[Mahks]

You can access the test case here : http://www.starlords3k.com/tests/clientWidth.php

Comment 2

[Boris Zbarsky [:bzbarsky]]

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....

Comment 3

[Alice0775 White]

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.

Comment 4

[Daniel Holbert [:dholbert]]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, interesting.  The comment 2 times were on Mac.

Comment 6

[Daniel Holbert [:dholbert]]

(I saw similar times to those described in comment 2 on Linux, FWIW.)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: fix v1

Comment 8

[Daniel Holbert [:dholbert]]

(If it's not clear, I'm only introducing the local variable 'frameMinISize' as a way of saving on line-length / awkward-wrapping.)

Comment 9

[Mats Palmgren (inactive)]

Comment on attachment 8608239 [details] [diff] [review]
fix v1

r=mats

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a33ee01bca86

Comment 11

[Ekanan Ketunuti]

https://hg.mozilla.org/mozilla-central/rev/a33ee01bca86