GeezerVison is showing github.com — Scrolling performance in matrix popup · Issue #293 · gorhill/httpswitchboard
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
Scrolling performance in matrix popup #293DescriptionUI performance is not optimal inside the matrix popup on request heavy websites (more than 150).
Tried on the following websites:
I can reproduce the problem easily by scrolling at fixed speed. To do that, you can use the middle-click scroll (middle click inside the matrix, move your mouse a bit down to begin scrolling, watch). At some point, the scrolling will stop being smooth and start to jitter.
Chrome tasks manager shows 25% CPU usage (100% / 4cpu ?) while scrolling.
Configuration tested
- Windows 8.1 Pro x64 with Chrome 35.0.1916.114 m / HTTPSB 0.9.4.4 (with/without others extensions), quad core desktop i5 CPU
- Windows 7 SP1 Pro x64 with Chrome 35.0.1916.114 m / HTTPSB 0.9.4.3, quad core laptop i5 CPU
Plugins usage are minimal in both cases:
- Widevine Content Decryption Module
- Adobe Flash Player
- Native Client
- Google Update - Version
Activitymy-password-is-password commented on May 23, 2014 gorhill commented on May 23, 2014
Video of the jitter
Very nice, seeing it is much better than reading about it.
Thought: I wonder if this could be related to the scroll wheel events rather than a display performance thing. If for some reasons the scroll wheel events are fired aperiodically, this would translate to the scrolling of the display. But then if so, that would be a browser issue as the extension doesn't listen to wheel event.
Does this also happen on other page content? (the extension is really just that, HTML page content, and rather lightweight compared to typical web pages out there). my-password-is-password commented on May 23, 2014 On the main page scrolling is smooth. gorhill commented on May 23, 2014 I brought the dev console for the extension popup ("Inspect popup"), and set a breakpoint so that if the extension code is called, it will break. But as I scrolled, the breakpoint never triggered, which means the stuttering happens on the browser side. Need to investigate more.
Edit: well, if I scroll with the mouse wheel while the mouse if over the matrix rather than over the scroll bar, the stuttering is quite more noticeable. There is code in the matrix to detach/attach the hotspot widget. Looks like I need to investigate how this could be done in a more efficient way.
And you are right, on Chromium 34, it is smooth, but Google Chrome 35, it sucks. Same extension code both version. gorhill commented on May 23, 2014 Alright, something definitely changes between 34 and 35. It's not the scrolling in particular, it appears in 35, there is a significant performance penalty detaching/reattaching the hotspot widget, this can be seen just by moving the mouse quickly over the matrix. On 34, the hotspot widget is locked to the mouse really, while on 35 it lags significantly behind.
Dammit. gorhill commented on May 23, 2014 Profiling wasn't helpful. Moving the mouse non-stop over the matrix in order to trigger mouseenter/mouseleave events on the matrix cells shows that 85% of the time is spent in the browser, 10% idle, and the other few percents left is the extension javascript code. gorhill commented on May 23, 2014 Dev tools > Timeline > Record > Move mouse over matrix cells
Chromium 34, "Paint" is fast (2ms) because a relatively small area is redraw -- corresponding to a matrix row.
Chrome 35, "Paint" is slow (28ms 88ms) because a very large area is redraw, corresponding to the matrix cell to which the hotspots are added down to the bottom of the matrix.
Need to investigate further later if anything can be done aside entering an issue with Chromium. Something changed in the rendering engine of the browser, and it appears to be less smart than 34, in the current case for sure.
Will provide snapshots later. my-password-is-password commented on May 23, 2014 
I did the Timeline thing you did and there were warning signs on Event (mouseover). In the details it says something about "Forced synchronous layout is a possible performance bottleneck.". Is that it? gorhill commented on May 23, 2014 No. The line you selected is 1ms, not an issue. It's the line where there is a long green bar which are the problem. On Chromium 34, there is no such long green lines, which is the Paint oepration. On Chromium there are never as large as the ones seen in your screenshot, 510x256, they are at most one matrix row high, and often limited to a cell size horizontally:
Something changed in the browser rendering engine, what you see above, repainting more than half the matrix (93ms), doesn't happen in Chromium 34. gorhill commented on May 23, 2014 And this is on Chromium 34: the worst I get is a "Paint" operation which took 3ms:
my-password-is-password commented on May 23, 2014 Why do my mouseover have the little warning sign next to it? gorhill commented on May 23, 2014 I get these warning if I check the option "Capture stacks". Chromium 34 returns the same warning. So I wouldn't worry too much about these. It's the paint operation itself the problem. Somehow their dirty rectangles algorithm is different in 35, the result is always much larger than needed. I will have to file a bug and see if there is any feedback.
I tried to change the CSS of the hotspots to force the region to be completely confined in the cell just to be sure, and nothing works. The fix will have to come from Chromium as far as I can tell. Profile the CPU shows that most of the time is spent browser-side, not javascript side. gorhill commented on May 23, 2014 I won't be able to open an issue with Chromium until after next release. Thing is, I have to spell out the steps requried to reproduce the bug, and having to details to install HTTPSB and put it in alloww-all/block-exceptionally mode is tedious. Next release there will be a quick setup screen so that will make the explanation much easier. my-password-is-password commented on May 23, 2014 Went into the Chrome flags and messed with everything that might help.
Enable this chrome://flags/#enable-compositing-for-fixed-position and relaunch. Popup scrolls smooth for me with this enabled. gorhill commented on May 23, 2014
Popup scrolls smooth for me with this enabled
Yes, it works.
The dirty rectangles are still too large though compared to what I see in 34, and moving the mouse over the matrix, the hotspots are not locked to the mouse pointer like they are on 34. my-password-is-password commented on May 23, 2014 What about these flags?
chrome://flags/#default-tile-width and chrome://flags/#default-tile-height
Are they the dirty rectangles you're talking about? I'm going to try setting them to 128.
Seems a lot smoother when i move over the cells. gorhill commented on May 23, 2014
Seems a lot smoother when i move over the cells
Yes, definitely a difference, the largest paint ops are smaller than before, and consequently the paint time. So is that what happened? They changed the default tile size? Even 128-height results in larger tile than what I can see on 34. (The height is the one which has the most influence on performance in this case). gorhill commented on May 23, 2014 Setting the tile to max size in Chromium 34 doesn't lead to the onerous paint operations. So there is something else going on here.
One switch I don't see in Chromium 34 is "Delegated Renderer (AKA Übercompositor)". When I select this in Chrome 35, speed is like Chromium 34, except that the rendering quickly become corrupted, i.e. doesn't work properly. gorhill commented on May 26, 2014 kikaxa commented on Jul 28, 2014 Same slowness on opera 24/chromium 37
If I enable #enable-compositing-for-fixed-position, scrolling is fast again(except for scroll start/stop),
hotspot widgets are still slow. ledti commented on Aug 9, 2014 I was just about to open a issue for this. Well, I made a short video which might help somehow.
https://www.dropbox.com/s/b2693wkgro4prr8/httpsb_lag.webm?dl=1 (60fps)
Tested with Chromium Version 38.0.2114.2 (287444) (64-bit) (latest dev-channel) on Arch Linux.
edit: and as said above, enabling #enable-compositing-for-fixed-position does fix the slow scrolling for me, but not the slow cells.
edit2: Possibly more useful video comparing 34.0.1847.132 (265804) (64-bit) and 38.0.2114.2 (287444) (64-bit) which obviously shows the regession in Chromium. The version switch happens at ~28 seconds into the video. Hope it helps.
https://www.dropbox.com/s/jtmpnlsx0evwghs/paint_lag.webm (better quality if downloaded). gorhill commented on Aug 18, 2014
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
