roost-im / roost-client

The official client for Roost.
MIT License
1 stars 6 forks source link

Overflow scroll is not composited #61

Closed davidben closed 10 years ago

davidben commented 10 years ago

The overflow scroll does not get split into layers correctly in Chrome, which makes scrolling, particularly on a touch screen, incredibly janky. (It's forcing repaints all the time.) You can see this by going into DevTools and enabling "Show paint rectangles" and "Show composited layer borders".

I believe the trouble here is that overflow scroll interacts awkwardly with stacking contexts, so it's more difficult to chunk it into layers. From what I've gathered, future versions of Chrome are supposed to be getting cleverer about this, but making it saner to composite is actually pretty easy:

Set message-pane-view (the element with overflow scroll) to position: relative, z-index: 1. This makes it create a new stacking context. This is worthwhile anyway as there's no reason for things within the scroll area to interact with those outside as far as z-index goes. It'll just cause weirdness and potential layer explosions if they overlap. (Note that, otherwise, z-indices of multiple panes even interact which is especially nightmare-ish.)

https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index/The_stacking_context

Next, move filter-bar and compose-bar outside (which you'll need to do anyway with the position: relative change). It doesn't actually make sense for them to be inside the scroll area when you'll be positioning them outside anyway. I've set them to display none and confirmed that that, along with the above change, things layer correctly. Looking at how the styling works, you'll probably need to introduce an element inside message-pane-view to contain all the scrolled bits and set that to overflow scroll. (The bit about stack contexts above would then apply to this new element.)

Note that you have to test this with multiple panes. Multiple panes is harder to composite if you do it wrong because of z-indices potentially interacting with each other without a stacking context.

andersk commented 10 years ago

Possibly related: Chromium #245656.

andersk commented 10 years ago

I watched davidben demonstrate his fix on Chrome 35 ChromeOS, but the same fix does not work for me on Chrome 35 Linux.

davidben commented 10 years ago

Yeah, I'm now kind of confused. Well then.

davidben commented 10 years ago

Apparently the answer is that Chrome will only composite overflow scroll on high-DPI devices or Android because it loses subpixel rendering. (Subpixel text + transparent backgrounds are problematic and overflow scroll apparently defaults to being very violently transparent.) Fun times.

jrafidi commented 10 years ago

Well, if davidben is confused, I'm not really sure I'd have any idea what to do o_o.

I'm going on vacation soon, but it would be nice if this got fixed. Would anyone be willing to hack at it?

davidben commented 10 years ago

What I wrote in the original report is still accurate. It just won't do anything outside of high-dpi devices because subpixels. But it will on Android, and high-dpi devices have 4x as many pixels to render, so those are the ones that really need it anyway.

(New enough Chromes (beta?) also seem to manage to chunk it into layers without this... there's some layer squashing work going on that's probably relevant, but they seem to make many more layers than should be necessary. Making the stacking contexts saner is probably a good idea in general.)