This decouples the management of Shadow from the scene window and allows
multiple items share the same Shadow.
Currently, kwin has a single scene graph, but it makes sense to create a
scene graph per output as they could have different layers, etc. This
would also allow QtQuick share more textures with kwin, which is worth
doing for optimization purposes in the future.
This makes shadow texture coordinates consistent with surface and
decoration texture coords and allows reusing window quads between
kwin items and qtquick items more easily.
This further decouples scene items from scene windows. The SurfaceItem
still needs to access the underlying window, I would like to re-iterate
over that later.
With this change, it will be possible to introduce WindowItem factory
function in the Toplevel class.
At the moment, we handle window quads inefficiently. Window quads from
all items are merged into a single list just to be broken up again.
This change removes window quads from libkwineffects. This allows us to
handle window quads efficiently. Furthermore, we could optimize methods
such as WindowVertex::left() and so on. KWin spends reasonable amount
of time in those methods when many windows have to be composited.
It's a necessary prerequisite for making wl_surface painting code role
agnostic.
Window quads need to be in some coordinate space. Since we want items to
be used not only for rendering windows, window-local coordinates do not
suffice.
This change makes scene items generate quads in the item-local coordinate
space.
The model matrix is used to map the quads to the global screen coordinate
system from the item coordinate space.
Since the quads are in the item local coordinate space, the mvp matrix
needs to be updated on every draw call. Given the render data, tracking
the last mvp matrix won't result in less glUniform calls. If this indeed
becomes a serious performance bottleneck, we can explore the possibility
of dumping mvp matrices in a UBO, which have been introduced in OpenGL
3.1.
The scene items depend on the scene windows for caching window quads.
The goal of this change is to move window quads management to item.
Merging window quads in one list and then splitting them is inefficient,
it will be highly desirable if window quads are removed from the public
api so we can optimize window quad management.
With this change, the window quad type becomes irrelevant to render
backends for the most part. Note that the Xrender backend is a bit
nitpicky about window quads, so the shadow item doesn't create generic
"WindowQuadShadow" quads anymore.
Currently, dealing with sub-surfaces is very difficult due to the scene
design being heavily influenced by X11 requirements.
The goal of this change is to re-work scene abstractions to make improving
the wayland support easier.
The Item class is based on the QQuickItem class. My hope is that one day
we will be able to transition to QtQuick for painting scene, but in
meanwhile it makes more sense to have a minimalistic internal item class.
The WindowItem class represents a window. The SurfaceItem class represents
the contents of either an X11, or a Wayland, or an internal surface. The
DecorationItem and the ShadowItem class represent the server-side deco and
drop-shadow, respectively.
At the moment, the SurfaceItem is bound to the scene window, but the long
term plan is to break that connection so we could re-use the SurfaceItem
for things such as software cursors and drag-and-drop additional icons.
One of the responsibilities of the Item is to schedule repaints as needed.
Ideally, there shouldn't be any addRepaint() calls in the core code. The
Item class schedules repaints on geometry updates. In the future, it also
has to request an update if its opacity or visibility changes.
