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
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
> 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
> > 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
> > 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 :)
vdr mailing list