Building a lower-latency GC

Re:Building a lower-latency GC by chongli on Friday April 10, 2015 @08:34PM (#9357873)

the difference between 1ms and 15ms is nothing, but the difference between 16ms and 17ms is everything. UI application animations are like train schedules. If you miss one train by only a microsecond, you still have to wait the entire time until the next train arrives.

This is why we need a better display protocol. Why are we still treating our displays like synchronous, scanline CRTs? The display should have a simple buffer into which we can do random reads/writes at any time and the affected pixels will be updated immediately. This would solve all of these problems (and eliminate video tearing)!

[ Parent | on HN ]

Re:Building a lower-latency GC by throwawaymylife on Friday April 10, 2015 @10:09PM (#9358122)

Yes, this would be much better than the status quo, and hopefully technologies like "gsync" will bring something like it to us soon. But this approach will still result in microstutter from frames being displayed at somewhat random times, that may or may not be perceptible (I've never used such a display). Obviously a bit of microstutter is preferable to tearing or missing frames entirely under heavy loads, but really, a synchronous refresh rate would be ideal, if only our process schedulers were designed to give strict priority, more reliable vblank timing, and some degree of safety from preemption to the foreground UI process.

[ Parent | on HN ]

Re:Building a lower-latency GC by Akkuma on Friday April 10, 2015 @10:12PM (#9358132)

IIRC, Nvidia G-Sync and AMD's Freesync essentially accomplish what you're talking about.

[ Parent | on HN ]