Fosdem was really cool and exciting.
Many interesting talks and a great way to meet all the people I've mailed or heard about ... and all those I haven't known before .... and drink some beer with them.
I am really looking foreward to next year's fosdem, thanks guys for the great time :)
The Caciocavallo talk was quite impressive (although I still have troubles with pronouncation), I guess their work will boost Java's popularity for embedded systems. Unfourtunatly I missed the first part of Karl Helgason's talk about Gervill.
My talk went ~ok I guess, nobody fell asleep. I just talked a lot about not really related stuff like Java2D in general to get my 30min filled somehow. Thanks nobody recorded videos ;)
Unfourtunatly Java talks colided with some Xorg talks I planned to attend, however Michel Dänzer talked to me after my presentation about some problems I had with X :)
The open-source radeon/ati driver is in a pretty good shape, once intel is stable and fast again and radeonhd pushes the r600/700 branch to mainline, we have >80% of hardware with good drivers (Hopefully in Fedora11), with the only exception of AMD's Catalyst.
Michel had a great idea about how handling fallbacks better. Currently there are several different heuristics when to move a pixmat to video-memory and when it should stay in system-memory.
The problem is such heuristic descisions are based on what happend in the past, which often means its hard to get it right - better would be a prognosticator to get an idea what will happen in future ;)
A way this could be archived would be some kind of delayed rendering:
All rendering commands could be buffered in a queue of e.g. 50 entries, and the current operation could make migration descisions based on what it knows to come. If the current operation could be done on the GPU, the image contents are in RAM and in the queue are 5 operations triggering a fallback, it may be more efficient to not move the image to VRAM and do work by the CPU, avoiding the later readback to RAM altogether.
This would help drivers/GPUs which provide only basic RENDER accaleration, like Nouveau with <= GF5 or for frequently use of unaccalerated stuff (AddTraps, A1 masks, frequent XGetImage, ...). If the queue is not full, X processes painting commands faster than the client so less optimal descisions would not hurt (the smaller the queue, the more it behaves like default the "Always" heuristic). However would be a lot of work especially without deep knowledge of the code , I'll have a look in the Summer holidays :-/ Back to the pipeline ... I am still distracted by the problem with xcb's socket handoff mechanism, no idea whats going wrong. If somebody knows xcb (and unix sockets, ...) a bit, I would be really happy for any help.
Its not a lot of fun to work on a pipeline locking up after 5s, without knowing the cause :-/