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

List:       kwin
Subject:    Re: RFC: Multiple clipping
From:       Rivo Laks <rivolaks () hot ! ee>
Date:       2008-02-11 21:14:17
Message-ID: 200802112314.17609.rivolaks () hot ! ee
[Download RAW message or body]

Ühel kenal päeval (esmaspäev 11 veebruar 2008) kirjutas Lubos Lunak:
> On po 11. února 2008, Rivo Laks wrote:
> > What I like about the patch is that it makes the code more readable by
> > hiding the clipping stuff in the PaintClipper class.
> >
> > What I'm a bit concerned about it that we should now always render
> > geometry multiple times - corresponding to the number of rectangles in
> > the clip region.
>
>  I don't know any better way to do that though. Stencil is slower AFAIK
> (although this code could make it easier to switch and even programatically
> decide).

Yes, switching might be good idea for the future. We could switch to 
stenciling if there are more than n (with n = 3 or so) rectangles.

> > Actually, if nothing push()es additional regions then the number of
> > rectangles in clip region (= number of times geometry need to be
> > rendered) should be same as ATM, right?
>
>  Yes. Either its the whole screen, or the (often one) changed regions. If
> there are more places that need updates the code could even optimize the
> region similarly to SceneOpenGL::Texture::optimizeBindDamage().

Are you sure we could do region optimization there? Wouldn't it cause problems 
if we use e.g. bounding rect of the clip region and thus paint outside the 
actual clip region?

> > So in that sense it shouldn't actually have
> > any performance impact as long as the effects aren't using it.
>
>  When talking about performance I was mostly wondering about the overhead
> of the extra clipping. There are additional OpenGL calls with this patch
> that aren't there now.

Calling glScissor() shouldn't have that much overhead. The minor state 
switches shouldn't be too bad either. I'm not completely sure but I think 
compared to the rest of our rendering code, the introduced overhead should be 
minor.

Rivo
_______________________________________________
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]