3 ms·
The flip side of something like this is that it creates a "floaty" feeling, due to delaying UI update for several runloop passes (jumping from one queue to anot
by LeoNatan25 12y ago
The flip side of something like this is that it creates a "floaty" feeling, due to delaying UI update for several runloop passes (jumping from one queue to another). Sometimes this is more acceptable but often it is not. If you played with Paper, and felt it was "floaty", now you know why. If it didn't bother you, I guess you are less sensitive to this. Not to say this library is useless, like most things, when not abused, good can come from it.
- ScottGoodson 12y agoCurious to better understand what you mean—in my experience, this is not true at all. All touches / gesture handling are direct manipulation with no delays at all. All the asynchronously-prepared content is rendered in advance with a large offscreen buffer, so in general it should be done rendering before it's onscreen. In the cases where you scroll really fast and get to something that hasn't finished rendering, the alternative in a regular app architecture is to simply stutter (block the UI) until it's done rendering. This framework can be used in very flexible ways, such as "try to render everything offscreen, but if it's going to come onscreen and hasn't finished yet, block and wait for it to be done". Even that approach will result in a much more responsive feel while ensuring that you have the same guarantees as a synchronous UI about content being finished rendering when it is visible.