iXce’s blog

Worse and worse… 12 days and no news. I hate holidays, heh. Nevertheless, I have written more than 2500 lines during these 12 days. Let’s have a quick overview over all this code

What’s new?
Two Compiz plugins!
The first one is something that I missed from Beryl, bottom cube caps. The new “cubecaps” plugin supports top and bottom caps, correctly blends caps color with the images (e.g. if you select a black cap color, the result won’t be completely black whatever the image is as with the previous “cube” plugin caps, but will be your image on a black background), and supports caps when there are more than 4 viewports (actually one could also enable them for 3 viewports by changing a single integer in the source file (currently at line 288 of cubecaps.c at commit 6d463e3), but it might look wrong if image is too big). Finally, clamping is done using clamp_to_border extension if available, which avoids weird lines when using non scaled images with alpha.

I’ll add some screenshots when I’ll be able to upload them… I am currently using my cellphone to post this, sadly.

The second one is a lot more specific : it displays some visual feedback of what you are doing with your mouse and your keyboards. More specifically, when you hit one of your mouse buttons it displays (when enabled) a little mouse in the bottom right of the screen with the button you hit highlighted, until you release it. Likewise, when you press a modifier key (Alt, Shift…) it displays a nice rounded rectangle in which the name of the modifier is written in the bottom left corner of the screen. It’s pretty hard to describe how it actually looks with words, but I hope you get it anyway. The main use case if for showing used key bindings when demonstrating/teaching the usage of an application.

Again, screenshots will come

I began working on a third plugin that would handle metacity -> Compiz -> metacity switch and move windows from the workspace they were on to the corresponding viewport upon startup and do the opposite upon shutdown, but there’s another core problem that blocks it (plugins are initialized after screen and windows were initialized, during which windows are all moved to current workspace).

I also happened to need a quick way to test some Cairo drawing before using it for the final application (which could, for instance, require compiling before testing, which is kinda annoying when you are trying to find right values for a simple drawing). I wrote a “cairoDrawingArea” PyGTK widget which handles the drawing of a Cairo surface (plus a patterned background and/or borders). One just has to write a child of this function and write the draw () method to do the actual Cairo drawing. I included the whole thing at the end of this post. I know I could/should have just used the write_to_png function on the Cairo surface, but dealing with nautilus/eog is just so unhumane and slow, while I needed (again) a fast way to view the result of my changes.

Most of the code for this script comes from a quick PyGTK Tic Tac Toe game I wrote to show a friend how one could write a fully working “software” in less than 2 hours. By the way, I am wondering if it would be possible to write an AI that would have no clue on the rules of a simple game such as Tic Tac Toe, and learn them round after round.

Last but not least, I fixed some bugs and mem leaks in my colorfilter plugin and cleaned the code a lot. There is now only one remaining thing to do for this plugin before it gets considered as done : fragment program parameters. Shouldn’t be too hard, but I am not sure of the way to cumulate filters using parameters (maybe it is just impossible).

What’s wrong?
I definitely can’t fix Filters Manager problems :/ I tried writing the base rgb -> hsv -> rgb fragment program using Cg, but it resulted in a 120 lines long fragment program, while poor Intel 900 GMA chipsets only support 96. Pretty sad, heh. The other problems (randomly borked cumulative filters preview and a strange OpenGL Invalid Operation error on first action on one of the previews when they are both displayed) are still there as well, but I think I could probably workaround them by having just one OpenGL drawing area which would process a queue of drawing operations

What’s next?
I’m quite unsure… I’d like to finish my Summer of Code, but it’s sadly held by the Filters Manager problems and by some bugs in Compiz Core that won’t be fixed before next release (which should hopefully happen pretty soon… I guess I’ll have to wear back my release roller hat for Fusion). I have done a lot of Compiz coding (some patches which I discussed with David and finally got a wider solution, fixing numerous other problems, some other patches that might make it after next release, and the two plugins), and I currently don’t have much ideas on what I could do (even though I would be very happy to find a good reason to learn more about OpenGL ). I have some mathematics related things planned as well (involving convex hulls, hypercubes and such), and some web coding which is becoming really high priority. Getting CamlUI ready for Windows and fixing the handling of toplevels must also be done (I would like to write a similar gedit plugin, if I can find some time to do so). And I do need to finish cairo-swissknife. So much things to do and so little time

Off topic.
I am looking for a real touch screen bigger than 10″. I would really really like to try to code some touch screen specific apps, but all I found was either fake touchscreens or unavailable laptops (which would actually be better than a simple touchscreen, I don’t really care about money as long as it’s less than 2000€). Hints welcome

(more…)

Phew, 10 days without a single post! It’s about time to dump some news =)

What has been going on since last post? Well, I attended the French “Libre Software Meeting” (a.k.a. RMLL), which took place in my city (Amiens) last week. I held a Compiz Fusion stand from Tuesday to Saturday, demoed it a lot, had some historic/ethic/technical discussions with several people. I think I succeeded at proving that Compiz Fusion isn’t just about eyecandy but is able to improve usability as well. Even though I have sometimes been asked to show atlantis, firepaint, water or burning windows, I think that Cube is still the most impressive thing we have, especially with the pretty reflections it now has. Isn’t it a bit weird to talk about impressive things just after writing the word “usability”? *cough*

I wrote today (a bit late, I admit) a nice demo script that shows the most well known Compiz Fusion features. The script uses PyGTK for the text messages (such as features names) and uinput to send keyboard/mouse events to Compiz through the kernel. I will upload it as soon as I will have cleaned it and commented it.

What about the color filter stuff? Well, I have a nearly usable Filters Manager, but I have some issues when it comes to finishing it.
First, I am now unsure on how to show the Source/Replacement pickers. The first possible solution is the one I published in the previous posts. The second one is a bit more complicated : the two rings would be concentric. The user would be able to move the marker in the inner one to select source hue, and move the whole outer ring to select replacement hue (by making source/replacement aligned under the marker). I wonder if that solution is more difficult to use or not…

I still miss the replacement shader source, I seriously need to get some kind of high level shading language to fragment program compiler compiled asap.

The other problem is that I have no clue on how to do the “Cumulative Filters” preview ><. To make it right I guess I would need to use just the same code as what is in Compiz Fragment Interface, but then I think that this code should be another shared library that Compiz and I would use (and not a Compiz core part that one would have to copy/paste). I probably need to mail David (Compiz core developer) about it. *laziness*

What am I working on? I am spending a few days at writing some Compiz patches to fix the most annoying issues I am facing (mainly Metacity => Compiz switch problems). I also have a working window workspace-to-viewport patch for those who would want it (for instance, when switching from Metacity to Compiz, windows which were on workspace 3 are moved to viewport 3). A similar viewport to workspace patch is in my todolist. I am also planning to try to fix some feature regressions from Beryl in Cube and Rotate soon.

I am going to write a simple Python/PyGTK/PySQLite application tomorrow to let my father’s students fill information forms which would get added to a local SQLite database and then imported into his class website. Simple but useful.

Color filtering stuff is being worked on all the time (I am actually doing other things while not working on it, not the opposite). I am going to implement some suggestions into the Compiz colorfilter plugin soon, fix some bugs tomorrow as well, and I have recently fixed some gShaderEdit’s previewArea redrawing problems.

Real life? My parents really love going to lost villages without serious modern means (read : without a single cybercafé in a reasonable range) and I have no reliable way to get internet access. I am checking my emails at least 4 times a day though, thanks to my faithful cellphone. If you need me, just mail me.

Last thing, huge thanks to EPPLUG (my local LUG) for the awesome work they did before and during the meeting!

Erm, I just found what was wrong with gShaderEdit on Intel & al. I wasn’t redrawing the window *cough*. This *problem* is now fixed, but I don’t like the end result anyway : moving the window is dodgy, enabling/disabling the shader is dodgy (by dodgy I mean that black frames or part of black frames appear for a few seconds), the gl area is drawn directly on the screen and not on the window (so that if you have a window above the gl area you still see the gl stuff on top of it). I am probably going to add some kind of buffering tomorrow, so that I would just draw the frame once (it would be a lot lighter for CPU/GPU by the way), or just completely change the way I am doing things *sigh*.

Update : I was unable to sleep with this issue running.. I have just fixed it in a much better way : the application just draws the GL frame once, dumps the pixels with glReadPixels, creates a python array from the pixels data and creates a Cairo ImageSurface from the data array. A quick Cairo transformation flips the surface vertically (the initial pixels are y-inverted). The result surface is then simply drawn on the widget, saving precious GPU and CPU clocks and avoiding ugly bugs.

Just for the record, I haven’t found a single “gl Pixels to cairo surface” function using Google Code Search & al, so I thought I could post mine here :

def dump (width, height):
    '''Dump current GL context pixels into a cairo surface'''
    glPixelStorei (GL_PACK_ALIGNMENT, 1)
    # Dump pixels to a string
    pixels = glReadPixels (0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE)
    # Create a python array from pixels data
    data = array.array ("c", pixels)
    s = cairo.ImageSurface.create_for_data (data, cairo.FORMAT_ARGB32,
                                            width, height, 4 * width)
    # Flip surface vertically
    surface = cairo.ImageSurface (cairo.FORMAT_ARGB32, width, height)
    cr = cairo.Context (surface)
    matrix = cairo.Matrix (yy = -1, y0 = height)
    cr.transform (matrix)
    cr.set_source_surface (s)
    cr.paint ()
    return surface

Update 2 : *sigh* I just figured the current code is buggy. It looks like the color format is wrong : glReadPixels produces RGBA data while cairo.ImageSurface.create_for_data expects BGRA… (I already faced this issue while writing the hue picker, but I’m not sure on the way I should fix it there :/)

Update 3 : actually, it was easy Just had to define GL_BGRA (PyOpenGL is definitely kinda outdated) and that did it!

We are now reaching the half of this Summer of Code, and it is about time to review what has been done so far.

(more…)

Here is a quick preview of the filter generator UI that will allow users to create their own color filters :

That’s just a preview of the UI though, mainly because I need to write a fragment program that can handle HSV color representation (HSV => RGB and RGB => HSV translations).
Comments welcome, especially since I really suck when it comes to usable & humane user interface design

After yesterday’s rant, I wrote my very own Hue Picker in pyGTK. It is meant to be very simple and straight forward : it just exposes a “changed” signal and two useful functions (get_hue / set_hue).

The usual preview :

(the “Source hue : [23 ^]” is just a placeholder and isn’t part of the widget)

Full source included below.
The ring drawing code is a mostly direct python port of C GtkHSV’s one.

(more…)

Hurray! School is (pretty much) done for this year, and my some of my long delayed work-in-progress projects are getting to an usable point. Summer of Code is now – at last – my main and only focus for the rest of the summer

I have just packed all my previous thoughts and finally decided on how to do it all.

1. Use HSV (Hue, Saturation, Value) color representation – it is just the most appropriate color space for that kind of stuff, especially since it’s the representation used by most color pickers (a color ring to choose hue and a triangle to choose saturation and value).
2. Write a generic fragment program loading plugin for Compiz. This generic plugin will have to parse fragment program source to plug it into Compiz’s fragment interface (which makes programs combinations (for example blur + negative + blur) possible). I’m probably going to make sure that other plugins would be able to easily reuse the loader (it would have been pretty easy with the basic library functions in Beryl, I will have to check what can be done at the moment in Compiz, using the newly introduced cube/rotate sharing bits might just be the solution, but I haven’t had the time to actually read it).
3. Extend the generic plugin to match the required features (mainly cumulative filters and filter quick switch).

I will hopefully have a “working” generic plugin by the end of the week. The parser shouldn’t be a huge deal (5 or 6 hours in the worst case), and wrapping the generated code in a Compiz plugin shouldn’t take more than 2 hours. Sounds doable

On a side note, gShaderEdit now also supports vertex programs (the detection of the program type is done on the fly according to the header of the program, which should either be !!ARBvp1.0 or !!ARBfp1.0 as standardized by the ARB)

Meh, I’ve been way too busy these days with school. Happily I should be mostly done with this year in a bit more than 40 hours among which 7 hours of examinations.

Anyway, I was able to pack together a simple but nice shader editor. It currently only supports fragment programs, but it works well. It’s built around pygtkglext and python-opengl, and makes use of ctypes to bind all the fragment programs related functions. Supporting vertex programs shouldn’t be too hard, actually most of what’s needed for it is already in place, it just needs some GUIfication.
All the required dependencies are in Gutsy’s Universe (pygtkglext wasn’t in Feisty’s).

Here’s a screenshot (click on the thumbnail to view the full resolution picture) :

Fresh-from-git source can be found at http://guillaume.segu.in/code/gshaderedit.git/ :
$ git clone http://guillaume.segu.in/code/gshaderedit.git/
$ cd gshaderedit
$ python gshaderedit.py

Should you find any bug, please report it to me by mail (you can find my address in the AUTHORS file).

As part of Summer of Code 2007, I’m going to work on color filtering through Compiz/Beryl.
The final goal of this project is to provide a flexible and efficient way to filter colors, switch through different filtering schemes or easily create custom filters.

Roadmap
June 18 : fragment program shaders test application to check the effect of a filter on an area of the screen or a picture (there’s currently no such software, only QShaderEdit which doesn’t support shaders on textures).
June 20 : filters (both test filters to see what color blind or vision impaired people actually see and corrective filters)
June 30 : working plugin using pre-defined filters
July 2 : easy switching through a customizable list of filters
July 10 : cumulative filters support
July 31 : configurator enabling user to preview the effects of a filter or a set of filters (using as much parts of the program used for testing filters) as well as making his own
August : debug, improvements, random ideas implementation, testing

Please note that this roadmap is just a kind of draft, especially since I might be still quite busy with school until June 17th (*sigh*, there are three written tests remaining, one per Saturday).