[haiku-appserver] Re: moving windows using 2D HW ACC
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 18 Jan 2005 17:13:46 +0100 CET
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:
