Hacker News Reader

Comment by panic | Hacker News Reader

I don't know about Android, but UIScrollView does all its work on the main thread of the app.

This is not strictly correct. CoreAnimation does it's work in a background thread, so the mechanical work of scrolling pixels is not done on the UI thread unless you are doing custom drawing. Under the covers its a texture so the scrolling is really just translation.

If you want to be pedantic, this isn't quite right either. CoreAnimation does some work on the main thread to encode layer properties and send them to the render server, which is in another process, not another thread.

The important part isn't the amount of work it takes to render, it's that event handling is serialized with all the other stuff happening on the main thread.

Thanks. I assumed iOS was like Windows. Although Windows also has scroller controls that you create on the UI thread but delegate the actual event handling to the compositor.

A compositor can only do scrolling if the app is written with a retained mode API. The low-level APIs in Windows are immediate mode, whether GDI or Direct2D.

For most of time, ScrollWindow / ScrollWindowEx was how you scrolled. It doesn't know what to draw in the invalidated region because it's an immediate mode API.

In Direct2D you can use e.g. a translation to get the renderer to draw a bigger bitmap in a different section of the window, but you need to render the bigger bitmap (i.e. assemble your own retained mode). There's no free lunch.

I'm talking about the UWP/XAML/DirectComposition world, which admittedly is not game-related.

Reply on news.ycombinator.com