[haiku] Re: [GSoC]: who is willing to mentor this year?

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Thu, 12 Mar 2009 00:25:44 +0100

Axel Dörfler schrieb:
Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
On Wed, Mar 11, 2009 at 5:35 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx
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. :-)

Best regards,
-Stephan

Other related posts: