On Sat, 2006-04-15 at 15:58 +0200, Thomas Liebetraut
wrote:> Hello everybody,
>
> I finally understood (or better: I think I understood) Compiz' way of
> decorating windows. There are still some things that I still don't get.
> For instance, there is the frame layout (see attachment) of the event
> windows and I just don't know *why* this works.
> However, I think I understood the basic way how things work, including
> the texture mapping with quads and so on.
> My plan is to add real theming support to g-w-d (via plugins, as
> discussed on this mailing list and ubuntuforums.org and as noted in the
> ToDo file for g-w-d). Unfortunately, I don't think that this can be
> achieved (at least not the way I want) the way windows are designed
> right now.
> My understanding of current window drawing:
> There is one single texture that contains all the information of the
> decoration. This texture is as small as possible and not as large as the
> whole window to save video memory. To get, e.g., vertical window borders
> of the full window's height, the area containing information about the
> border is stretched. The whole border is just one single line of pixels
> in the texture, but as there is no pattern, it can be drawn repeatedly.
> This is also done for all other things that can be stretched like this
> and is achieved by texture coordinates that map texture coordinates to
> window coordinates (relative to the application window, i.e. the window
> we see of we kill all window managers). The decoration plugin uses these
> informations (they are stored as a property in the application window)
> to create a texture and to translate the coordinates from the window
> decorator (they are in screen coordinates) to coordinates that can be
> used in the OpenGL scene. The window decorator also listens for events
> on "hotspots", e.g. the close button, and notifies the decoration
plugin
> via a XDamage event that the texture changed (and the close button
> becomes highlighted).
>
> Now, I don't like this way of drawing window decorations. It makes
using
> patterns for window borders (I imagine Aqua's brushed metal or
something
> like this) impossible (or *very* memory expensive, as the texture would
> be the size of the window, for *each* window) and thus limits the
> possibilities of theming that we actually have. It is also hard to make
> the decoration layout completely ustomizable. If I think of themes that
> have the title bar at the bottom or the sides of the window, this would
> be difficult. Having multiple event buttons (one close button in the top
> right corner and another one on the topleft corner, to the left of the
> window icon) would also be difficult, as the structures to store these
> event windows (they are implemented as seperate XWindows) are limited to
> four buttons (close, maximize, minimize and context help) in the
> decorator itself. The number of texture coordinate mappings is also
> limited (to 9), so more complex texture maps are not possible, either.
Wrong, all things listed here can already be done with the existing
decoration system. You can have an infinite number of quads and buttons.
And the titlebar and everything else can be placed wherever you like.
g-w-d is just not doing all these things yet.
>
> What I want is a possibility to theme the windows in whatever way one
> could imagine. Place the window buttons n the top-left corner of the
> window instead of the top-right. Move the title bar to the buttom of the
> window. Have arbitrary shapes of the decoration. Have as many close
> buttons and title bars as we want. Have patterned decorations. Have even
> animated decorations.
> >From my point of view, the current approach can't do this (at least
not
> all of it).
It can do all of it, perfectly.
>
> After having talked to pwuertz on #xgl@freenode, who explained to me how
> textures in OpenGL work, I have two possible solutions.
> 1. Instead of using just one texture for the whole decoration, use as
> many textures as the currently active decoration plugin (read: theme)
> wants. The plugin says "I need 42 texture elements, and here are the
> coordinates, width and height for each element: [list]" and Compiz
tries
> to show these elements. There is a way of multitexturing a polygon, but
> pwuertz told me that this is a real performance penalty and not all
> drivers/cards support it and the number of textures is not specified. So
> Compiz should create a polygon for each element the theme wants. A
> window would then consist of many polygons (as real objects in 3D apps
> do): one in the center to show the actual content and further polygons
> arranged around it, one for each decoration element.
> Each of these elements could have a different texture. And the position
> of each element (except for the actual window) could be arranged by the
> theme, so there is full customizability.
More than one texture wont give you anything that can't already be done
with the existing system. It will just be harder to get it as efficient.
>
> 2. The other solution would require some trust in the theme plugins.
> We have the window's pixmap in CompWindow::pixmap. This pixmap could be
> resized by the theme plugin so that there is additional space to draw
> its decoration on the same pixmap. That way, we would not have an
> additional texture/pixmap for each decoration but would use the existing
> texture that we have anyway and just make it a little big larger (and
> memory-expensive) and still have the possibility to place decoration
> elements wherever we want.
Not a good idea, mostly because client windows are created for specific
visuals which might not have an alpha channel and it would mean that
windows without an alpha channel would not be able to have decorations
with an alpha channel.
>
> I see that both ways have drawbacks. The drawback of the first method is
> that there are more polygons in the OpenGL scene and this produced more
> rendering overhead. Furthermore, the first way would require more
> in-depth changed in Compiz itself. The second method is more risky, as
> we would have to rely on the data the theme plugin gives us. It could
> report wrong border sizes and thus mess up window placing. Or it could
> even draw over the window's content.
> I think the better way it the first one, nevertheless. We don't have a
> very complex scene with many polygons and a few more or less for each
> window would still be way less polygons in the scene than 3D games had
> some years ago, so the additional overhead is negligible.
> But it requires much more work on the window structure of Compiz. Work
> that I can't do as I don't know much OpenGL. But I would really
> appreciate if someone could do it, so that I can write a new decorator
> with plugins.
>
> Please post your ideas and suggestions about this topic. We definitely
> should first discuss the matter before someone starts to write code that
> turns out as unusable later.
>
The existing decorations system can do everything you've mentioned. The
only thing I though about adding is a more efficient way to specify
repeating patterns but I wont do anything about that until we have a
decoration that proves it necessary.
-David