wrote:
Just a few remarks about the idea page:
* "Identify and fix performance bottlenecks in our app_server" is

probably not a good task for a student, besides, it's fast enough
for
me :-) Maybe something like "Implement hardware cursor support in
the

app_server" would be a better project.

Is the latter even complicated enough for a GSoC project?

Well, at least I looked at it several times in the past, and didn't do
it then. Not sure if it's really complicated, but it's more involved
that one would think.

The current app_server approach is that there can be one object that's
composited on top of all windows. If the user is dragging transparent
icons, this bitmap is combined with the cursor shape. And this is what
makes it a bit complicated. Or maybe not so much, I don't know. I guess
the existing code would be used unchanged if there was a hardware
cursor, minus the combining with the cursor. Simply use the drag bitmap
without combining it with the cursor. The cursor would be drawn using
the graphics hardware without the rest of the code needing to care. In
any case, the problem is also that the current compositing works best if
the screen bitmap is located in RAM. That's the case for VESA and
explains why dragging something in VESA feels so much smoother, it
happens even without any flicker. The app_server will do an on the fly
compositing of the screen and the drag bitmap and write the result into
video memory. The screen is therefor never seen without the drag
bitmap/cursor. But when using accelerated drawing, without my double
buffer hack which has it's own set of problems, then the drag bitmap has
to be removed from the screen, composited at a new location when moving
the cursor. That causes flickering and the actual compositing is much
slower too, because it reads from video memory, whereas VESA mode only
ever writes to video memory, never reads. A solution would be to create
a temporary RAM based cache of the screen bitmap as it's seen without
the drag bitmap, and do on the fly compositing as well in accelerated
mode. For this purpose, the screen would need to be read from the clean
regions before the composited image is placed there. It would have to
maintain a dirty region to know when client windows have repainted
content after the RAM copy was made. It's not possible without
flickering though, unless one does tripple buffering and uses the
current double buffer for acceleration hack + the RAM cache. All this
isn't rocket sience. But the problem is motivation. On a Core 2 Duo
@1.83 GHz, using Haiku completely without any acceleration feels
absolutely fast enough for all intends and purposes. If I had a much
slower computer, with a slower RAM->video mem connection, I might think
differently. But as it is, my personal itches are other stuff. :-)