Mmm... That sounds too specific Currently the UI toolkit is very universal, but such trick will require specific hacking for the specific design

The widgets are all happily drawing to their normal mode buffer and the rotation to different orientation is another layer on top of the toolkit right? The toolkit says it was updated so the upper layer rotates it to the screen. What if the list widget could have a callback that is invoked when the list scrolls. This callback could inform the upper layer about the new and old area boundaries so it can blit the old and rotate the new. Its not like a transparent slider widget over a list widget is all that universal to begin with.

Yes, but this upper layer that will perform blitting already rotated image will need somehow know which parts of scrolled area are need to be copied from offscreen buffer because overlapping widgets.
Although... It seems that this parts can be easily calculated by intersecting window's child widgets with the scrolled area. Something like:
(scrollarea_before_scroll ∩ child_position) ∪ (scrollarea_after_scroll ∩ child_position)

Hey all!
I'm very impressed of Mitrandir's work and all your investment in this project!
I was too busy past days but I am back. I had a little time today and I've started to write some kind of presentation. You are very welcome to edit is (cuz my english r bed enough to screw up this work) and to post there new ideas in a list in the end of the document.

About memory consumption.
Now the UI demo eats ~2.4mb RAM. This is nearly ok.
BUT that doesn't include memory allocated by X process for pixmaps, window backing stores and other resources!
According to my measurements, X gets fatter by ~4.2mb. So the total is 6.5mb, that is not so ok...

UPD: I have measured memory size of minimal GTK program: 3.9 mb RSS + 0.6 mb X = 4.5 mb total. Yeah, it seems that i use too much pixmaps...
(but keep in mind that lxtest UI totally combined from pixmaps while gtk app needs no any)

auouymous, I have implemented your advise about scrolling. This really makes rotated scroll to be as fast as unrotated, thanks But there is an issue: If I blit already rotated window's content while scrolling, this breaks double-buffering... Copied window's content overrides overlapping transparent glow and then glow is redrawn on the top. So the glowing around seekbar's thumb starts flickering and this looks very ugly.
Of course, this can be easily solved by adding one more buffer in the current chain that will store rotated content. But one more 800x480x32bpp buffer will add ~1.5 mb to the X memory...

If Simp could have AD2P support for bluetooth headphones (with hardware buttons support too) it would be fantastic.

BTW, THANKS for the effort.

Why 32bit buffer if the screen is only 16bit?

I thought all of the widgets were drawing to the buffer and then you rotated that buffer onto the screen? So why is the slider being drawn twice? Wouldn't it get drawn into the buffer and rotated with the list?

You are right, 16bpp
(But I use many 32bpp-pixmaps while drawing because 16bpp ones doesn't support alpha channel)

When i scroll window's rotated content by direct blit window->window, this overrides slider's thumb. Then i redraw overlapping widgets into the buffer and then do blit buffer->window. After the first blit intersecting part of slider disappears, after the second it appears again and this results in flickering.
It is possible to eliminate flickering if i would scroll only part of window's content that will not override other widgets.
This can be done easily in our case, but in common case this will require complex logic to compute this area with substraction of rectangles and this problem isn't solvable in all cases.

UPD: I found that tablet's X server supports DBE extension that can automatically provide double buffer for window. I wrote primitive program to measure X memory size for window with and without DBE double buffer and it seems that DBE uses same amount of X memory as hand-coded double buffer. The only advantage is that DBE buffer automatically resize to match window's dimensions.

Hardware buttons are done via AVRCP, not A2DP. As for A2DP itself, unsure how easy it is to pull off using gstreamer. I think the effort to date regarding A2DP on Maemo4 have focused on mplayer.

In this thread (in russian) hacker with nick svs57 successfully played mp3 to A2DP via gstreamer with self-compiled MAD decoder.
So, A2DP support is certainly possible