On Wed, Jul 23, 2008 at 09:21:01PM +0200, Thomas Hilber wrote: > 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. > Hmm.. I still don't understand why you need to do this in the first place? > > 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. > Ok. > > 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. > Does this mean XV extension (or X itself) does not provide a way to "wait for retrace" out-of-the-box.. and your patch adds that functionality? Sorry for the stupid questions :) -- Pasi _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
