No. I don’t agree. Actually Haiku misuses this hook for offscreen drawing (did it myself as well sometimes for some tests). It is actually meant for a virtual desktop in the sense that the desktop is larger than the physical resolution of a screen, where the screen in fact is a small viewport onto that desktop. The position of this viewport is set by moving the mouse around to keep that mousepointer inside the viewport.
I have spent a lot of time in the past on my drivers (nivida, matrox, via, neomagic) to make this work flawlessly on the BeoS. I must say I was dissapointed to discover that Haiku in fact messes up in this respect.
Instead you/we need to create new hooks for offscreen compositing…
On a sidenote, I have on my old laptop a nvidia driver version that uses scaled_filtered_offscreen_blit instead of using overlay to accelerate video onto the desktop. This is using a non-existant hook I created to do this. Don’t know the exact status of it, apart from the fact that the function indeed worked. since no colorkeying is possible that way, we’d need to take into account context menus etc on top of video to only blit around that, which makes it very important to do the scaling subpixel precise to prevent artifacts on the ‘part’ rectangles edges.
Anyhow: The above expresses my personal opinion, in which I stronly believe considering use of B_MOVE_OVERLAY (only worked with hardcursor on BeOS since there was no means to track a softcursor there).
You can imagine I nolonger really look at that hook since Haiku does not recognize apparantly the intended use of this hook. Another sidenote: also the old style hardcursor support is broken for years already in Haiku (I guess since adding a fullcolor hardcursor support hooks).
Yes, I could probably make that hook work, but it would require Haiku to use it as intended, as I would be looking pixel precise to the hardware response to find the exact hardware imposed restrictions: which, at least is the old days, were also unknown and not handled on Linux dirvers.
So all in all I guess I would like it very much if Haiku developers would think long and hard about which hooks we will keep supporting for what purpose(s), and which hooks can disappear (all acc hooks from the looks of it), and which new hooks will be implemented. Considering the route we seem to want to take to only support acceleration via MESA/3D/Vulcan, all acc hooks can be deleted from the current accelerant I’d say (though I really miss them, at least on older systems, but also for video playback (since backend scalers went into oblivian in favor of acc via 3D engine AFAIK) I must say)
All in all a big response to your simple question, sorry about that. This has apparantly bothered me for years (misuse of the MOVE hook )
Still, it can be used for a temporary hack solution of course, but I really hope new hooks will come along at some point. BTW Thank you very much for your dedication and very hard work on Haiku on all kinds of subjects! Love following your work…