Closed Bug 1165667 Opened 7 years ago Closed 6 years ago
Excessive delay on call to clientwidth, with CSS Flexbox & Direct2D
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
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.
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
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
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+
You need to log in before you can comment on or make changes to this bug.