On Thu, Aug 14, 2008 at 01:15:58PM +0300, Petri Hintukainen wrote:
> to, 2008-08-14 kello 11:25 +0200, Thomas Hilber kirjoitti:
> > Does the Xserver poll for some resources not available or something?
> Maybe the driver is waiting for free overlay buffer ? Some drivers wait
> for free hardware overlay buffer in simple busy loop.
a good idea, but in the case of 'xserver-xorg-video-ati' true hardware
double buffers are supported. If a new PutImage() comes in the DDX simply
toggles to the other double buffer and starts to write there. No matter
this buffer ever has been completely read by CRT controller.
So there is no mechanism waiting here for something as far as I can see.
> Usually this can be seen only when video player draws Xv frames faster
> than the actual output rate (ex. displaying 50p video with 50p display
To see the effect in practice I just set the VGA frame rate to several values
slightly below 50Hz (i.e. in the range 49.94 - 49.99HZ). Applying all
these 'low' frame rates lead to dropped fields as expected.
But Xserver %CPU always stays around 2%CPU maximum.
The only exception here is if I press the 'OK' button. The OSD 'time-shift'
bar showing up then costs about 16%CPU. Strangely enough if I open the
'recordings' OSD which covers almost the entire screen this takes only
my xineliboutput OSD setup is as follows:
xineliboutput.OSD.AlphaCorrection = 0
xineliboutput.OSD.AlphaCorrectionAbs = 0
xineliboutput.OSD.Downscale = 1
xineliboutput.OSD.ExtSubSize = -1
xineliboutput.OSD.HideMainMenu = 0
xineliboutput.OSD.LayersVisible = 0
xineliboutput.OSD.Prescale = 1
xineliboutput.OSD.SpuAutoSelect = 0
xineliboutput.OSD.UnscaledAlways = 0
xineliboutput.OSD.UnscaledLowRes = 0
xineliboutput.OSD.UnscaledOpaque = 0
But anyway all these values still are in the 'green area' and are
compensated by the patch.
A value of 40%CPU as Gavin posted above I never could reproduce on my system.
There must be broken something.
vdr mailing list