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

  • From: Truls Becken <truls.becken@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Thu, 12 Mar 2009 08:41:45 +0100

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?


Other related posts: