On Fri, Nov 01, 2002 at 10:46:40PM +0100, [EMAIL PROTECTED] wrote: > > I think the main reason for the lack of a standard effort is the > > varying requirements of the projects proposing these solutions. The > > mplayer folks (and some xine/etc authors) want some kernel solution > > that's independent of X and DRI and fbcon, since they want to support > > different levels of exlusive or direct access. Some other projects, > > such as DirectFB, only care about this in the context of fbcon itself. > > And then the DRI folks only care about X, and so solutions from that > > arena may not work outside of a running X server. > > > > Resolving this is going to be difficult: X developers don't ever seem > > to want to consider compatibilty with driver layers that aren't X, for > > one. > > -- > > Billy Biggs > > And exactly because things have become messy like that, one should use a > method that is as simple as possible, but powerful enough. A function > returning milliseconds to next vblank has no unnecessary complexity, > and is still powerful enough for all purposes.
The number of ms till the next vblank will be a number between 0 and 17, usually nor more than 12 or so. It cannot be accurate to more than 3ms or so if it comes from the X server. The minimum time most systems can sleep is on the order of 10ms, and the precision they can sleep at is also on the order of 10ms. This isn't powerful enough for *any* purpose as far as I can see. -J _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
