[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Video sync
From:       Philip Falkner <philip.falkner () gmail ! com>
Date:       2006-11-22 2:40:09
Message-ID: 200611212140.09166.philip.falkner () gmail ! com
[Download RAW message or body]

On Tuesday 21 November 2006 16:19, Lubos Lunak wrote:
> On Tuesday 21 November 2006 20:55, Philip Falkner wrote:
> > Attached is a patch which adds support for syncing to video retrace when
> > using direct rendering (enabled by default).
>
>  Oh boy, I was really afraid of this one. Pretty much everybody who's tried
> to add compositing to an already existing WM seems to have run into some
> unspecified timing problems or something, at least as far as I've heard,
> and I thought it would be this one. Well, the mysterious beast may still
> show up somewhen later then ;).
>
>  Applied, thanks. I've also added the syncing to the non-db case, as I
> think it makes sense there too, doesn't it?

Uh, yes it does.  I guess I should check the code more thoroughly next time.

> > Note that this WILL increase time between repaints (since that's the
> > point)
>
>  Eeek, my ShowFPS effect 8-O. I'll probably have to add some special hack
> to prevent it from looking so bad now :).
>
> > but prevent flickering/tearing.  The speed difference is not that large
> > here, and the improved appearance is more than worth it.
> >
> > This doesn't change the default 50fps refresh rate.  We could detect the
> > screen's refresh rate with RandR, but do we want to?  If we do, should it
> > be for all compositing engines, or just OpenGL?
>
>  I'm not sure, probably yes and for all.
>
>  I'm not aware of any way to sync the non-OpenGL case and QTimer cannot
> guarantee the period to be exactly the value given, but even then I think
> it makes sense to try to at least somewhat to match the refresh rate even
> for XRender, to minimize visual lag with high-refresh displays. As long as
> the refresh rate may be manually configured otherwise I think it cannot
> hurt. Especially given that the current code has throttling to prevent the
> compositing from hogging the system, so the timer rate could be
> theoretically set even to zero.

Okay.  So, manually specified refresh rate comes first; if none, fallback to 
RR-based; if none, fallback to 50Hz?  All within some sanity limits, of 
course: 1-1000Hz sounds about as far as we'd want to go.

In thinking about this, it occurred to me that we need to listen for RR 
notifications, don't we?  If we're using RR-based refresh rate and it changes 
mid-run, well, it won't be the optimum rate anymore, but that's not so bad.  
But what if the resolution changes?  Currently, OpenGL goes really bad 
(unviewable here), XRender goes sorta bad (most noticeable when increasing in 
resolution), and Basic seems okay.  Probably this is the picture/window/pixmap 
that we draw to not being the right size.

That would mean we'd need to recreate what we draw to on RR-change 
notification.  The simple (but expensive) way to do that would be to stop 
compositing, tear down the scene, make a new one, and start compositing 
again.  I wouldn't think RR-based changes would be that frequent, so maybe we 
could get away with this?

-- 
Philip Falkner
_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]