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

List:       kwin
Subject:    Re: RFC: Multiple clipping
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2008-02-11 20:40:37
Message-ID: 200802112140.37729.l.lunak () suse ! cz
[Download RAW message or body]

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).

> I'm not sure how many rectangles that region usually consists of, 
> do you have any info on that?

 One :) ? See below.

> 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().

> 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.

> We should probably note in apidox that it's not a good idea to form complex
> regions as it might slow down painting but otherwise it can go in IMHO.

 Well, ok. Since I probably won't have a chance to see your reply in time, 
I'll leave this for the time after two weeks or whenever I'm again able to do 
it.

> In the patch I don't see where the PaintClipper::push() is used when we're
> doing a partial update of the screen. Shouldn't something in Scene push the
> correponding region before the painting begins?

 Maybe. It's not there currently, since the region argument is still used and 
that's what limits the painting, but I guess that one PaintClipper after 
pre-paint and before paint wouldn't hurt and would catch code not extending 
the region in pre-paint as necessary.

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