[compiz] g-w-d.c -> my head spins

[David Reveman]

On Fri, 2006-04-07 at 19:06 +0200, Mirco Müller wrote:
> Am Freitag, den 07.04.2006, 14:37 +0200 schrieb David Reveman:
> 
> > > 	Why did you do it this way David? It appears to be very non-obvious.
> > > Are there speed-issues demanding such an approach or other things going
> > > on behind the scene, which I still fail to see?
> > 
> > What way?
> 
> Here a few - more specific - questions.
> 
> 	Why does the code in draw_shadow_background commented with /* bottom */
> have no visible effect? I can comment out that portion and the whole
> drop shadow stays intact after I did recompile/install and a full
> restart of Xgl/g-w-d/compiz.

Because that part is usually not mapped to texture coordinates, in some
situations it still can be (e.g. while resizing a window quickly) so it
should be kept there.

> 
> 	Why does the code snippet in draw_shadow_background marked with /*
> bottom right */ actually draw the (real) right side and lower right
> corner of the shadow? From the setup of the matrix there I would expect
> this to only draw the lower right corner of the shadow. Where does this
> "stretching" come from?

That's the area that is always mapped out to texture coordinates.

Make sure you understand the decoration property
(gnome-window-decorator.c:756) that is used for communication between
the decoration plugin and the decorator. Understand how this property is
used is very important.

By setting .xx, .xy, .yx, .yy in the quad matrix. Stretching and
flipping of x, y coordinates can be achieved.

> 
> 	Also having placed a printf() for x2 and y2 after /* bottom right */
> the printed values for a simple xterm window are confusing to me. While
> I would expect to see values of something around 340 x 200 or so I get:
> 
> 	 13,0 x 28,0
> 	 13,0 x 28,0
> 	124,0 x 28,0
> 	270,0 x 28,0
> 	340,0 x 28,0
> 
> 	I would expect the window-local coordinates to be around 340 x 200 in
> the lower right corner.

It's very important that minimal textures for decorations are created.
For a maximized window we definitely don't want to create a texture the
size of the window. That would be a huge waste of our precious video
memory. We create a minimal texture that is big enough to fit the window
title and buttons, most parts can just be stretched to match the actual
window size. The coordinates you see are coordinates in this minimal
texture.

> 
> 	Where does the actual calculation of the whole size and placement of
> quads take place? Or is this hard-coded in the all the quad arrays for
> shadows, win and switcher?

Most of it is currently in the structures at the top of
gnome-window-decorator.c. Those structures are copied and modified
slightly to have a size that matches the currently used font and so on.

> 
> > The decorator creates minimal pixmaps and coordinates in these pixmaps
> > are mapped relative to he actual windows.
> 
> That's what those arrays of quads are for? 

see my answer to the previous question.

> 
> > A decorator doesn't have to use that similar "pixmap -> window" mappings
> > as I'm currently doing in g-w-d, those mappings just work well with the
> > current decorations.
> 
> 	For the tweakable shadows I've in mind the mapping will have to be
> dynamic (at least at initialization time, when g-w-d is started). I
> don't know yet how any settings from gconf will "get to" g-w-d. But
> Thomas "tommie-lie" Liebetraut seems to have figured out that somehow.

It shouldn't have to be anymore dynamic than the current decorations.
g-w-d is already using gconf for some things, like the titlebar font.
Just add some more keys; opacity, radius and x/y offset for adjusting
the shadows.

> 
> > I know the code lacks comments, g-w-d code is pretty hard to read. I
> > wrote that code very quickly so that I could release everything at
> > xdevconf.
> 
> 	I can understand this. Furthermore I could also easily imagine, that
> the superfluous public outcry regarding "Novell should release the code
> to Xgl & co!" created negative publicity in the eyes of the managers of
> Novell resulting in putting pressure on you to get things done faster,
> thus commenting the code and making everything more easily
> comprehendable by outsiders a non-priority. But I'm just widely guessing
> here :)
> 

-David