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.
Originally Posted by curaga
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.