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

List:       kwin
Subject:    Re: [GSoC] Unit Testing Framework
From:       Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= <mgraesslin () kde ! org>
Date:       2011-03-18 6:08:44
Message-ID: 1300428524.14056.2.camel () Nokia-N900-51-1
[Download RAW message or body]


----- Ursprüngliche Mitteilung -----
> On Thursday 17 March 2011 15:11:25 Jon Ander Peñalba wrote:
> > I'm interested in creating the Unit Testing Framework for GSoC.
> 
> Cool, looking forward to any new contributor!
> 
> Regarding the testing, what I would like to see is some tests that
> verify if   operations do not cause unnessary "blits" (i.e. copies of
> pixel data).
The idea for this gsoc is not to include the compositor. Getting a test framework for \
effects is of course also required but needs some reorganisation in the framework \
first. That's what is the main motivation for the commits of the last weeks.
> 
> First, every function that can cause a blit should have a way to record
> the   rectangle of the modified region, and (unless transparency is
> involved) verify   that this region, or a part of it, is never modified
> again. On my system,   screen updates get really slow with multiple
> overlapping windows, even if only   the frontmost window changes (and it
> isn't transparent) and having a way to   track such unneccessary blits
> would be awesome.
We know where the unneeded blits happen: first we cannot really handle the situation \
of overlapping windows if translucent windows are involved. Second we also repaint \
areas changed on different desktops. My motivation to fix this properly increased \
since at work I have to use apps thinking it's fun to do constant repaints :-(

Third we had a clipping bug in our rendering scene which is fixed in master.
> 
> Second, many operations currently cause repaints in regions that aren't 
> affected by the operation at all. While we have to "Show Paint" effect
> to see   such repaints, there should be unit tests that verify that
> indeed only a   specific region is updated by a particular operation.
> 
> Finally, a way to track uninitialized pixel data would be nice. In
> earlier   releases, and even today, I am seeing blits of either random,
> gray, black, or   white pixels, depending on moon phase. Having tests
> that ensure that nothing   is ever copied to the screen that isn't
> "approved" to be generated application   content would be very nice. This
> means attaching additional test information   to internal pixmaps,
> framebuffers etc. and ensure they are never blitted to   screen unless
> they contain data.
> 
> Of course it should be possible to disable all such instrumentation for 
> release mode to get maximum speed.
My idea is to get a standalone windowed compositor to simulate the effects. That \
would not require to add anything into kwin itself ;-)

Martin
> 
> Christoph Feck (kdepepo)
> _______________________________________________
> kwin mailing list
> kwin@kde.org
> https://mail.kde.org/mailman/listinfo/kwin

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