[haiku-appserver] Re: moving windows using 2D HW ACC

Hi Adi,
>       I just realized... the code that I wrote for moving windows is not 
> using HW at all!. Here's why:
> 
>       Out windows are not perfect rectangles, a partially visible window 
> is 
> not a perfect reactangle and the HW only provides ACC for moving a 
> perfect rectangle.

A partial visible window consists of perfect rectangles. You need to 
break your non-perfect rectangles down into perfect rectangles and then 
accelerate them. As simple as that.

>       For example, when I'm moving a window I'm saving it's entire 
> contents 
> into a (ATM: dynamically allocated) buffer and then paste that into 
> the 
> new location. I know it's not good, but ATM it servers its purpose.
> 
>       Now, the question is: how do we make this better?
>       Well, this is why I write to you, I want you to give in your ideas.

If you move a window (accelerated), you blit it: copy and paste it in 
the visible graphicsbuffer in the graphicscard RAM.

>       In the mean time I would like your opinions regarding those:
> 1. See which is the biggest rectangle in the new window's visible 
> region 
> and use 2D ACC to copy from old location.
Correct.

>Then copy all other rectangles 
All smaller rectangles of course can be copied using 2D acc as well. 
You simple make a list of all parts that are currently visible but need 
to be moved. That list you send as a single ACC command.
Only parts of a window that become visible at the new location (and 
where not visible at the old location) are software copied from a 
source in main mem to the destination onscreen.

> by copying them into main memory and then paste to new location. 
> (that 
> is if the new location overlaps the original location, else copy each 
> rect using HW ACC)
Overlaps you do not need to concern yourself with. It's the task of the 
accelerant to blit in the right direction. Just give a source and dest 
rect list to the accelerant's command.

> Rudolf, what will happen if we use the 2nd option when using VESA 
> drivers?
All commands that can be done accelerated by a capable driver you need 
to have software fallbacks for. If a accelerant does not export a hook, 
you insert your fallback instead. VESA modes only uses all fallbacks.

> I mean... can we request a virtual screen of twice the actual 
> resolution and use that area as a backbuffer and flip when needed?
I don't think so. That could be done with a VESA3 driver, but not 
(good) with VESA2.

I don't get why you want a back buffer BTW concerning this. Just do it 
as I described?

> Another question about VESA: does it support blit? Maybe it is a dumb 
> question but I just don't know...
No. No acc at all. You need to do everything you can think of in 
software.

Bye!

Rudolf.

Other related posts: