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, -Stephan