I'll preface this by saying that I'm not a graphics guru. However, I have been doing graphics-related work off and on for the last ten years (although nothing too fancy, mostly 2D stuff).
The key to MythTV (or any program, really) being able to render a display without tears or choppiness is really in two things: 1. Being able to know when the vertical sync is, and, 2. Being able to react to the vertical sync event in a timely manner
With regards to (1): Basically, the way that images are displayed on the screen, or a monitor (I don't know about projection units or the like) is that the image is drawn left to right, up to down, via an electron beam sometimes called the "raster". When the raster goes out of the viewable area, then you are said to be in the vertical blanking interval (VBI). For the purposes of this discussion, we'll ignore that some TV signals have Closed Captioning data sent during the VBI on the input signal.
Generally speaking, when you are within the VBI, you may update any portion of the screen that you want, and have no tearing or artifacts (because the raster isn't updating it). It is extremely important that you update your screen fully during the VBI, or, at the very least, update your screen before it is drawn by the raster (otherwise, you will see tearing/jitter).
If your output driver/software doesn't have any way of knowing when it is within the VBI area, then you can't hope to accomplish this, and there are very good odds that you will see tearing or jitter.
As Isaac said in his response, DRM is one method. The OpenGL vsync is another.
Now, on with (2): Knowing when the VBI occurs isn't enough - you must be able to get control of things while you're still in the VBI to be completely effective (again, otherwise, you might be updating the screen while the raster is drawing it).
The biggest problem that MythTV faces is that Linux is not a real-time operating system (this problem is not limited to Linux, Windows suffers from the same fate). While the 2.6 kernel has a much improved scheduler (and I was actually at the Embedded Systems Conference today, discussing some scheduler related issues my employer is having on one of their products, with MontaVista, LynuxWorks and TimeSys to see if any of them can help us), it is still not real-time (like vxWorks). So, although you might know that you're in the VBI, your task might not have gotten it's time-slice from the kernel yet. This means that you have this precious time you should be drawing in, going to another task/thread, and by the time you get the time-slice, you might be out of the VBI.
What about RTLinux or RTAI Linux? This would give the realtime performance needed to respond to a VBI interrupt, the problem would be that the RTLinux code to interract with the graphics card would have to be written from scratch. Just a thought, I haven't really been following this thread.
Cheers,
Mark
<snip>
_______________________________________________ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
