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

List:       kwin
Subject:    Re: Effects and window rendering
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2007-04-28 12:32:16
Message-ID: 200704281432.17161.l.lunak () suse ! cz
[Download RAW message or body]

On pá 27. dubna 2007, Rivo Laks wrote:
> Hi
>
> I've ran into a problem with window rendering when working on the blur
> effect. ATM, order of effect function calls is this:
>
> effects->prePaintScreen();
> foreach(Window* w, windows)
> {
>     effects->prePaintWindow(w);
>     effects->paintWindow(w);
>     effects->drawWindow(w);
> }
> effects->postPaintScreen();
> foreach(Window* w, windows)
>     effects->postPaintWindow(w);
>
> (actually this is even a bit more complicated when translucent windows are
> involved. In such case first prePaintWindow() is called for all windows and
> after that paintWindow() and drawWindow() are called for every window)

 And it'd also need some indenting to show that e.g. paintWindow() eventually 
calls drawWindow()  ;), but yes, that's roughly it.

> My problem is that I need to know the number of translucent windows before
> anything is rendered. As you can see, this is not possible though, because
> prePaintWindow() is the only place I can get such information from prior to
> rendering, but it is called right before the rendering function for each
> window, so I can't collect data about all windows before any rendering is
> done.
>
> I propose to change the function calling order to make sure that first
> prePaintWindow() is called for all windows, then paintWindow() and
> drawWindow() and finally postPaintWindow() is called for all windows.
> So the order of calls, concerning effects, would be:
>
> effects->prePaintScreen();
> foreach(Window* w, windows)
>     effects->prePaintWindow(w);
> foreach(Window* w, windows)
> {
>     effects->paintWindow(w);
>     effects->drawWindow(w);
> }
> foreach(Window* w, windows)
>     effects->postPaintWindow(w);
> effects->postPaintScreen();

 It seems ok to me. Translucent windows are already painted this way, so 
painting opaque windows as a separate pass before that should be no problem.

> Note also that postPaintScreen() is called after postPaintWindow() in my
> proposal, since it seems to make more sense IMHO: we start screen
> rendering, then render all windows and finally finish the screen rendering.

 Ok. It shouldn't matter much in practice, since postPaints are mainly used to 
triggering repaints in the next round, but I agree it's more logical this 
way.

> On a sidenote, it seems that most effects could actually do without
> postPaintWindow(). It's mostly (only?) used to trigger animation repaints
> of a window which could just as well be done in paintWindow() unless I'm
> missing something here... I'm not proposing to remove this method though.

 Now it's the way you say. It didn't use to be, originally (possibly even back 
in the times when there was no addRepaint() and one had to damage the window) 
window damage was reset in SceneOpenGL::Window::bindTexture() and screen 
damage was reset after paintScreen(). Without post calls this would have led 
to repaints being mixed between current and next pass.

 I think the post calls could be removed, now that the resetting is done at 
the very beginning. Most post calls are really only used to triggering next 
repaint, with the exception of TaskbarThumbnailEffect::postPaintScreen(), 
which should paint the thumbnails in paintScreen() and not here, and 
VideoRecordEffect::postPaintScreen(), which also could grab the screen 
contents after calling next effect's paintScreen().  Making them to be last 
would be achieved by having them first in the effects order.

> Anyway, does anyone see any problems with changing the function order?

 No.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
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]