2006/8/22, Richard Cooper <[EMAIL PROTECTED]>:
It is hackishly possible in 2.6 kernels to sync to vertical retrace. Using the new HZ=1000 allows a timer to be set to signal the program somewhat near the time when the vertical retrace will occur, and using "realtime" priority will nearly guarantee that the process is executed at that moment, leaving the graphics software to sit in a busy loop waiting out the remainder of the time until the vertical retrace occurs, which wastes about 6% of the CPU (regardless of CPU speed, because it's the inaccuracy of the timer that causes the waste), but is ultimately better than the situation with 2.4 kernels where the HZ=100 made it impossible to do any better than wasting all available CPU time.
Current 2.6 kernel use a tick of 512. There is patch for tickless system but it's very hard to make it work well. Beside that, does "/dev/rtc" should do what you looking for ?
> Morale: Linux is just not what YOU want it to be, and other people > may actually care more about stability/security than smooth graphics. I don't know... I guess I'm just a genius. I don't know how else to explain the lack of flexible scheduling, vertical syncing, and a graphics API. I guess I have solutions to all sorts of problems to which everyone else believes there is no solution. Maybe I need to help humanity by creating a web site to document everything that I believe to be common sense as apparently much of what I believe to be obvious isn't.
The linux kernel was design to not care about graphics. That the x server job. There is minimum support for it, to have a display without xserver that's all. So if you want 2D graphics, the "standard way" is to use standard lib, like the xlib or the STL lib. Flexibility and stability is much more important in the linux world than raw performance, that come in second. There is lot of improvement on going. xlib begin to be rewriten, there new stuff like xgl, xrand, etc... So happy haking... If you find a clean way to modify how the API of framebuffer work, you could email there autors. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
