https://bugs.kde.org/show_bug.cgi?id=390698
--- Comment #11 from Vlad Zagorodniy <vladz...@gmail.com> ---
(In reply to Martin Flöser from comment #10)
> The general design of the compositor is described in scene.cpp,
> but I fear it's too high level to be of much help.
Thank you for pointing out. After digging the source code,
I have basic understanding how KWin works:
<-- the part with ApplicationX11/ApplicationWayland is omitted -->
- Application creates an instance of Workspace
- Workspace creates a bunch of objects, setups different connections,
starts listening for new clients, etc.
One of those objects it creates is Compositor
- Because Compositor is constructed in the constructor of Workspace
class, it delays its "full initialization"(Workspace::self() is
undefined). Compositor initializaton code does several things:
* picks scene plugin to use
* chooses refresh rate
* creates EffectsHandlerImpl(not really, it is provided by a platform)
* schedules performCompositing to be called every fpsInterval(not really,
it can be adjusted)
<-- PERFORM_PAINTING -->
performCompositing does several things:
* first, it makes a copy of the stacking order
* moves elevated windows to the top of the copied stacking order
* calls Scene::paint()
* makes bookkeeping stuff
* schedules itself
- Scene::paint() is implemented by a scene plugin(scene plugins live inside of
plugins/scenes/ directory) and it is supposed to call paintScreen.
paintScreen in turn:
* gets the time diff between the last frame and the current frame
* sets painting region
* calls EffectsHandler::paintScreen
<-- at this point screen is painted -->
* calls EffectsHandler::postPaintWindow for each window
Effects in KWin are implemented as a chain. So, by calling
EffectHandler::paintScreen
we "activate" the first effect, that one would activate the second, and so on.
In the
end, finalPaintScreen is called which would call either paintGenericScreen or
paintSimpleScreen(it is optimized). paintGenericScreen and paintSimpleScreen
share
some logic:
for each window w in the stacking order
- call prePaintWindow
call EffectsHandler::paintWindow if w should be painted
the effect chain is traversed and at some point Scene::finalPaintWindow()
is called
Scene::finalPaintWindow calls EffectsHander::drawWindow
it traverses the effect chain, again; in the end, Scene::finalDrawWindow
is called
Scene::finalDrawWindow calls Scene::Window::performPaint
- Scene::Window::performPaint is implemented by a scene plugin and does actual
painting.
<-- compositeTimer ticked, go to PERFORM_PAINTING -->
--
You are receiving this mail because:
You are watching all bug changes.
