On Wed, Jul 23, 2008 at 05:05:21PM +0300, Pasi Kärkkäinen wrote: > I assume RGB NTSC should work as well.. ? basically yes. The devil is in the details:) Just give it a try. > > When xine-lib calls PutImage() it checks whether to increase/decrease > > Xservers frame rate. This way after a short adaption phase xine-lib can > > place it's PutImage() calls right in the middle between 2 adjacent vertical > > blanking intervals. This provides maximum immunity against jitter. And > > even better: no more frames/fields are lost due to stream and graphics > > card frequency drift. > > > > Hmm.. can you explain what "increase/decrease Xservers frame rate" means? you simply adjust the time between two vertical blanking (retrace) intervals to your needs. This is done by lengthening/shortening scan lines that are not visible on the screen. Because they are hidden within the vertical blanking interval. > I don't really know how xserver or display drivers work nowadays, but back > in the days when I was coding graphics stuff in plain assembly (in MSDOS) I > always did this to get perfect synchronized output without any tearing: > > 1. Render frame to a (double) buffer in memory > 2. Wait for vertical retrace to begin (beam moving from bottom of the screen to top) > 3. Copy the double buffer to display adapter framebuffer > 4. Goto 1 that's very similar to the way a Radeon handles this when overlay method is choosen for XV extension: 1. the Xserver writes the incoming frame to one of its 2 buffers. Strictly alternating between the two. 2. the CRT controller sequentially reads the even than the odd (or the other way round dependend on the start condition) field out of the buffer. And then switches to the next buffer. Also strictly alternating between the two. You just have to take care that data is written the right sequence to the double buffers. So it is always read the correct sequence by the CRT controller. > So the video adapter framebuffer was always filled with a full new frame right > before it was visible to the monitor.. the same here. Otherwise the CRT controller would reuse already shown data. > So I guess the question is can't you do the same nowadays.. > lock the PutImage() to vsync? exactly. The patch tries hard to do this:) But to put it in your words: It's only a 'soft' lock. Loading the machine too much can cause problems. -Thomas _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
