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

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Thu, 12 Mar 2009 08:47:09 +0100

Truls Becken schrieb:
Stephan Aßmus wrote:

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. :-)

Just a thought, that is probably not possible: When using a hardware
cursor, would it be possible to set the cursor to a bitmap composed of
the dragged object + the cursor?

Yes, but only for a limited size range. Some graphics boards support 64 by 64 pixels maximum, some others probably less than that, some others perhaps more. It could be an optimization when the resulting bitmap is small enough. However, the current BeOS driver accelerant API does not support this, not even true color cursors. I don't feel confident I could change the existing drivers to support this. So if I was to implement this, I would first try to do without changing the existing accelerant implementations.

Best regards,

Other related posts: