Greetings everybody! I started looking more thoroughly at gnome-window-decorator.c and now my head spins and "hurts" and believe that I'm not going to achieve anything serious in terms of tweakable shadows anytime soon. It's far more difficult than I expected. While I (believe) to understand now the shadows are drawn, I currently don't get why there are 12 shadow-quads and not just 8 or 9. And why are the _shadow_quads only used in a function that is not called before a theme/style is changed? Has every window its own cairo-context? Furthermore there's no GL involved in drawing the shadows/decorations. Am I correct to assume that GL is only implicitly used via cairo, which is rendered through glitz in compiz' case? Unfortunately the list goes on. I should have looked this deep into g-w-d.c _before_ assuming I could add tweakable shadows to it. I'm currently looking like a jackass and feel just dumb for not really comprehending the code :/ Best regards... MacSlow -- email - macslow@bangang.de www - http://macslow.thepimp.net lowfat - http://macslow.thepimp.net/sponsor-it
Mirco M?ller wrote:> I'm currently looking like a jackass and feel just dumb for not really > comprehending the code :/Hardly :) The code is lacking comments, and I've had a hard time figuring parts out too. One thing I'd like to do at some point is go through one of the plugins and add some detailed comments explaining what each part does. The HTML tutorial is a good start but there are many details it misses out. For instance it took me a little while to figure out the animation scheme used ... in the past when I've done animation the algorithm I used was something like record the start time of the animation, for each loop around the paint code take the current time, calculate the "progress" as a value between 0 and 1 then lock the animation relative to that. So you specify in the code how many seconds an animation should last for. Compiz uses a different scheme in which the elapsed time is used to calculate the number of steps and each steps progress is defined as an option. The way the number of steps is calculated and what the "timestep" option does still isn't really clear to me, but when I figure it out I'll try documenting it for others. Likewise the screen grab API isn't too hard to understand when you figure it out but IMHO it's otherwise not obvious that "if (ss->grabIndex)" means "if the animation is currently in progress". thanks -mike
Am Donnerstag, den 06.04.2006, 14:38 +0200 schrieb Mirco M?ller:> I started looking more thoroughly at gnome-window-decorator.c and now > my head spins and "hurts"...After futher investigation my head now spins the other way round :) In the meantime I was able to identify all drawing functions responsible for the titlebar (I didn't touch the title and buttons), frames and shadow-elements. As an example I replaced them with simple opaque rects to see what part goes where. Actually I just draw the rects for the shadow and completely skip the frame-drawing functions (for reasons of clarity I draw the middle part of the titlebar too), because I'm currently only interested in the shadows. And this yielded another strange fact. Take a look at the attached screenshot. You might want to know that the drak grey and white parts should only be drawn in the lower left and lower right corner (at least that's what I would expect from the code and David's comments). Instead the lower left covers the left, lower-left and lower part while the white occupies the lower-right and right part. Yet I have to (hopefully) figure out how the local 2D-window-coordinate system works and how it relates to the matrix used in draw_shadwo_background(). I think only David can give some insight on why I see the colored squares arranged as they are. 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? Thanks in advance for _any_ kind of help! Best regards... MacSlow -- email - macslow@bangang.de www - http://macslow.thepimp.net lowfat - http://macslow.thepimp.net/sponsor-it -------------- next part -------------- A non-text attachment was scrubbed... Name: decoration-experiment.png Type: image/png Size: 7120 bytes Desc: not available Url : http://lists.freedesktop.org/archives/compiz/attachments/20060406/f54bf320/decoration-experiment-0001.png
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
On Fri, 2006-04-07 at 19:29 +0200, Mirco M?ller wrote:> Am Freitag, den 07.04.2006, 14:37 +0200 schrieb David Reveman: > > > What way? > > Ups... hit the Send-button to fast. I forgot some questions. Does this > field "gravity" in the point-structure mean "origin" of the local > coordinate system, e.g. a: > > { -6, -5, GRAVITY_NORTH | GRAVITY_WEST }, > > means this points origin is in the upper-right corner and it is moved 6 > units/pixels to the left and 5 units/pixels to the top?gravity flags are used to indicate relative to which window corner that the texture coordinate should be mapped to. e.g GRAVITY_SOUTH | GRAVITY_EAST, is the lower right corner of the window.> > What's the meaning of the align field in the quad-structure?Align field is only used when you set a max width or max height for a quad and is used by the decorator plugin to determine the position of the quad when max width or max height is reached.> > Where are the contents of the _shadow_quads array actually used? I only > see them being passed to decoration_to_property() where stuff is crammed > in data, which then gets passed to XChangeProperty(). With this last > call I'm totally put on a mental halt as I don't have any clues about > Xlib or X11's inner workings. This might be an indicator that I'm not > the right person for doing tweakable shadows.g-w-d puts all the quads that represent how a decoration texture is mapped to a window in an X11 property on the client window. This property is read by the decoration plugin. XChangeProperty is use for updating this decoration property.> > Sorry, for maybe asking stupid questions to obvious things... but I > feel really lost atm.That's OK, I understand that it's definitely not obvious how these things work. Thanks for not giving up when it's hard to understand. -David
To get you started, I wrote a small patch which adds some basic support for dynamic shadows to g-w-d. Left to do is to have it adjust the size of decoration pixmaps so that the shadows actually fit in them when made bigger than the default static shadows and the RADIUS, SIGMA... parameters should be exposed through gconf. If you feel like taking this patch and fixing the last pieces so that we can move it into CVS, that's great. If not, I'll probably try to finish it up in a few days. BTW, while writing this patch I realized that the convolution filter code in server was broken and I've now fixed it. So for the patch to work, you'll need update to current CVS version of Xgl. -David On Thu, 2006-04-06 at 14:38 +0200, Mirco M?ller wrote:> Greetings everybody! > > I started looking more thoroughly at gnome-window-decorator.c and now > my head spins and "hurts" and believe that I'm not going to achieve > anything serious in terms of tweakable shadows anytime soon. It's far > more difficult than I expected. While I (believe) to understand now the > shadows are drawn, I currently don't get why there are 12 shadow-quads > and not just 8 or 9. And why are the _shadow_quads only used in a > function that is not called before a theme/style is changed? Has every > window its own cairo-context? Furthermore there's no GL involved in > drawing the shadows/decorations. Am I correct to assume that GL is only > implicitly used via cairo, which is rendered through glitz in compiz' > case? Unfortunately the list goes on. I should have looked this deep > into g-w-d.c _before_ assuming I could add tweakable shadows to it. I'm > currently looking like a jackass and feel just dumb for not really > comprehending the code :/ > > Best regards... > > MacSlow >-------------- next part -------------- A non-text attachment was scrubbed... Name: compiz-gdw-dynamic-shadow-1.patch Type: text/x-patch Size: 4848 bytes Desc: not available Url : http://lists.freedesktop.org/archives/compiz/attachments/20060410/e80271a1/compiz-gdw-dynamic-shadow-1.bin