Quote Originally Posted by curaga View Post
I assume the scanline wait code is smart enough to calculate the needed time and to avoid the scanline catching up in the middle of a transfer.
You would either have to have the kernel driver pick apart every command buffer and estimate both the time required for each one *and* the screen area covered by the operation, or you would need to limit drawing operations to more-or-less the vertical blanking interval. Even that wouldn't cover the problem Drago is talking about, which is running into the scanline pause mid way through redrawing the screen.

You really need double-buffering to let the app or desktop manager draw complete frames without ending up displaying a half-redrawn screen and allow whole frames to be flipped in when complete.

*IF* your app/DE never redraws the screen but just makes a series of changes to small parts while leaving the rest unchanged you can get away with limiting drawing operations to a small part of the vertical refresh period, but AFAIK apps & DE's are less likely to work like that every year.