Summary: | Web Inspector: Large repaints while typing in the console tab | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Nikita Vasilyev <nvasilyev> | ||||||||||||||||
Component: | Web Inspector | Assignee: | Nikita Vasilyev <nvasilyev> | ||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||
Severity: | Normal | CC: | bburg, commit-queue, graouts, joepeck, mattbaker, nvasilyev, timothy, webkit-bug-importer | ||||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||
Hardware: | All | ||||||||||||||||||
OS: | All | ||||||||||||||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=155387 | ||||||||||||||||||
Bug Depends on: | 145324, 155902 | ||||||||||||||||||
Bug Blocks: | 152220 | ||||||||||||||||||
Attachments: |
|
Description
Nikita Vasilyev
2016-03-17 23:28:52 PDT
So far, I was only able to work around this issue by replacing flexbox with `position: absolute`. https://bugs.webkit.org/show_bug.cgi?id=145324#attach_273274 Setting `z-index` or even `transform: translateZ(0)` didn't improve anything. Adding the following reduces the paint area to the console prompt: #content { position: absolute; left: 0; top: 0; width: 100%; height: 100%; } However, it breaks sidebars for other tabs. (In reply to comment #3) > Adding the following reduces the paint area to the console prompt: > > #content { > position: absolute; > left: 0; > top: 0; > width: 100%; > height: 100%; > } > > However, it breaks sidebars for other tabs. Wouldn't a more specific selector work that affects on the console tab? (In reply to comment #4) > (In reply to comment #3) > > Adding the following reduces the paint area to the console prompt: > > > > #content { > > position: absolute; > > left: 0; > > top: 0; > > width: 100%; > > height: 100%; > > } > > > > However, it breaks sidebars for other tabs. > > Wouldn't a more specific selector work that affects on the console tab? When changing tabs, we don't change any class names for #content or its parents. For instance, we don't have anything like <body class="tab-console">. Do you think this would be worth doing? Created attachment 274730 [details]
Patch
Created attachment 274732 [details]
[Animated GIF] With the patch applied
Comment on attachment 274730 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=274730&action=review > Source/WebInspectorUI/UserInterface/Base/Main.js:549 > + console.assert(previouslySelectedTabIdentifier); I think this will assert the first time a tab is added and selected, since previouslySelectedTabIdentifier will be "". You should drop this assert and make the following line condition on if (previouslySelectedTabIdentifier). > Source/WebInspectorUI/UserInterface/Views/LogContentView.css:32 > + width: 100%; > + height: 100%; Does right: 0 and bottom: 0 work here instead? We usually don't use container based percents. Created attachment 274823 [details] Patch (In reply to comment #8) > Comment on attachment 274730 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=274730&action=review > > > Source/WebInspectorUI/UserInterface/Base/Main.js:549 > > + console.assert(previouslySelectedTabIdentifier); > > I think this will assert the first time a tab is added and selected, since > previouslySelectedTabIdentifier will be "". You should drop this assert and > make the following line condition on if (previouslySelectedTabIdentifier). That's exactly what was happening. Fixed. > > > Source/WebInspectorUI/UserInterface/Views/LogContentView.css:32 > > + width: 100%; > > + height: 100%; > > Does right: 0 and bottom: 0 work here instead? We usually don't use > container based percents. AFAIK, `width/height: 100%` work exactly the same as `bottom/right: 0` in this case. Replaced with bottom/right for consistency. Comment on attachment 274823 [details] Patch Clearing flags on attachment: 274823 Committed r198619: <http://trac.webkit.org/changeset/198619> All reviewed patches have been landed. Closing bug. Re-opened since this is blocked by bug 155902 This often causes me to get a completely blank/unusable Console tab when switching to the Console Tab for the first time. * STEPS TO REPRODUCE 1. Open Inspector 2. Switch to Timeline Tab 3. Close Inspector 4. Open Inspector 5. Switch to Console Tab => Blank, missing navigation bar, typing does not work This seem like a recent WebKit bug. Resizing the window makes the console show up properly as well as toggling `position: absolute`. I'll try to create a reduction. I used Timelines to profile repaint times. Before the patch: 5ms repaint. After the patch: 0.1ms repaint (x50 improvement). Configuration: MacBook Pro (Retina, 15-inch, Mid 2014) Resolution: 1440 x 900 (2x Retina) Web Inspector window was detached and was 50% of my screen width. Comment on attachment 274730 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=274730&action=review >>> Source/WebInspectorUI/UserInterface/Views/LogContentView.css:32 >>> + height: 100%; >> >> Does right: 0 and bottom: 0 work here instead? We usually don't use container based percents. > > AFAIK, `width/height: 100%` work exactly the same as `bottom/right: 0` > in this case. Replaced with bottom/right for consistency. I accidentally discovered that setting `height: 100%` alone reduces flexbox paint areas just as well as `position: absolute`! Created attachment 275013 [details]
Patch
Created attachment 275014 [details]
[Animated GIF] Before the patch
Created attachment 275015 [details]
[Animated GIF] With the patch applied
Comment on attachment 275013 [details] Patch Clearing flags on attachment: 275013 Committed r198747: <http://trac.webkit.org/changeset/198747> All reviewed patches have been landed. Closing bug. |