yesterday jeff asked me how much memory an applet using the new applet api used so i looked into it. i really only cared about writeable memory.

i was shocked to find out that a very simple applet uses almost 1.5MB of memory.

for comparison i made a few small gtk programs to test. i’m just sharing the results here in case anyone is interested

a program that calls gtk_init/gtk_main uses about 160kB of heap

a program that creates a single window and shows it uses about 250kB of heap

a program that creates a single gtklabel and puts it inside of that window before showing both of them uses ~1200kB of heap

so creating the first gtklabel uses almost a meg of memory. i looked into this and it turns out that a huge chunk of this memory is allocated by pango inside of its opentype handling code “harfbuzz”. the code responsible for the vast majority of the memory allocated in this way is the harfbuzz-gpos code. i have no idea what this code does but if i had to guess, it tells you how far apart two glyphs need to be drawn in order to look right.

i know that recently (december 2006) behdad has been working on this thing called harfbuzz-ng. i sure hope it fixes this problem. :)

that’s all, really.

so, a lot of people probably know that i’m playing around with some code that will let me test out ideas that we can merge into gnome-panel in the future. one of these ideas is the idea of using x compositing instead of the terrible hacks we have today to support transparency in the applets.

the approach, i thought, would be to simply paint alpha transparency onto the background of the applet. when the xembed was done, this would allow the background of the panel to be seen through the applet. or so my thinking went, at least…

turns out, this isn’t how it works at all. when you draw alpha onto the applet, it just draws the alpha straight onto the panel toplevel window. the result is that the panel itself becomes transparent (through to the desktop).

i got annoyed and started looking for places to complain about this insanity. i went to #cairo. there i found owen taylor, carl worth and keith packard, who all very patiently explained to me why i was wrong. after being told why what was happening was in fact the correct behaviour i went off and did an awful lot of learning. i now know what all of those xfixes, xdamage, xcomposite, xrender things mean.

i also coded a solution to the problem — an in-panel compositing manager. i’ve called it panelcompositebin. it’s a normal gtkbin. when you place a widget inside of it that has its own gdkwindow (like a gtkeventbox, or more usefully, a gtksocket/plug pair) it will composite the contents of that window onto the background of the parent containing it. the effect: real applet transparency without the awful hacks.

this code has potential to be used in other places, which is why i make it available here. i’ve also included a small test application. if you find other uses for it, please let me know. any feedback about bugs is also appreciated. you need gtc to build it.

one note: i don’t think anybody has ever done this before. as such, this code exposes a bug in the x.org server where expose events aren’t sent when they should be. it’s on keith’s todo list to fix it, but he’s a busy man. for now, in a fit of irony, i have added a timer to the code to generate synthetic expose events once per second :)

meta-note: keith thinks the bug lies in the miValidateTree code in xorg in mi/mivaltree.c. i find this code utterly incomprehensible, so i’m not much help there. if anyone else wants to try their hand at tracking the bug down, i’ve written a small test app to help you: exposetest. the goal is to get the parent to see the expose events.

panelcompositebin.

question 1: when did creative commons start offering the No Derivative Works add-on to creative commons licenses?

question 2: how long until we see the iPodOnly add-on?

((ipod art lifted from rstevens of diesel sweeties))

edit: i understand that for some people and some types of work, “no derivatives” makes sense. i understand that even “you have to give me money” makes sense as a license. i don’t have anything against either. i merely think that someone who says “you can’t use my work in the creation of another work” isn’t really putting their work into what i would call a “creative commons”.