Subject:
Re: Area Copies and clipping code
From:
"Greg Haerr" ####@####.####
Date:
1 May 2000 04:55:30 -0000
Message-Id: <121001bfb329$71e928c0$15320cd0@gregh>
Morten,
I like very much your ideas on the scrolling code. I've been
very underwater here just this past week, put will be coming
back up for air soon. I agree with your algorithm with
one small change: I want to make sure that the scroll
code works more at the engine level, rather than just
for the nano-x api. With this in mind, instead of
painting the background, the scroll code should
basically "expose" the area, which then for Nano-X
would paint the background, but for win32 would end
up sending a WM_PAINT event, which may or
may not paint the background, and then ask
the app to redraw. This is almost what you are suggesting,
I think.
Also, for setting up the source rectangles to essentially
"tile" the plane, here's an idea of how to accomplish that:
If the engine region function GdSubtractRegion were used to
subtract the union of all higher-z-order windows
from the source rectangle, then the result could be used
as the "hidden" rectangles, I think. I've not had time
to fully visualize this, the hidden rectangles may have
to be heightened by the scrollup value.
I'll post some more specific comments shortly.
Regards,
Greg
:
: I need an optimized screen scroller, which I'm not sure is implemented
: right now?
:
: Ricard mentioned some time back IIRC that he had tried the blitter but
: that it was both slow (generic code probably), and that it didn't handle
: overlapping copies (other than copying towards the upper left corner of
: the screen). I haven't had the time to investigate the details myself,
: so I hope you can help me out a little here before I start coding. Thanx!
:
: These are problems I intend to solve if not already solved, but I'd like to
: do it properly - but properly in this context means handeling clipping
: properly, which is kind of a challenge. I may not implement clipping
: in the first version (we will not need it), but this should be kept in mind.
:
: My ideas on the subject:
:
: Set up the clipping rectangles for the source area to copy. For each
: of the source rectangles, calculate the corresponding destination
: rectangle, set up clipping rectangles once more for the destination,
: and perform the equivalent of a GdArea operation using the AreaCopy
: driver operation for each of the destination rectangles (from the
: single source rectangle).
:
: Several problems here:
:
: 1) We need to have two sets of rectangles available, the source
: rectangles that we go through one by one and copy, and the
: destination rectangles which must be set up from scratch every
: time we move to a new source rectangle.
:
: 2) We need to have "hidden rectangles", e.g. the entire
: source area needs to be spit into rectangles that are visible,
: and rectangles that are invisible - totaling the entire area.
: This is so that we can copy the background color onto those parts
: of a window that "slides out from underneath" another window - e.g.
: those parts of the destination area whose source is hidden.
:
: 3) Overlapping copies. Solving the overlapping copy problem at the
: driver level is easy, just reverse the loops or use temporary
: storage depending on X and Y direction of copy. But at the
: higher level, we have to make sure the rectangles that eventually
: gets copied is copied in the right order.
:
: I don't think (1) is available today, but should be possible to implement
: without to much effort.
:
: As for (2), I don't know if it is available. I suspect it to be "not
: entirely simple" if not available today. Solving (3) may have to be done
: by making up a "play-list" of all rectangles that needs to be copied and
: blanked, and then sort them (X and Y directions as criteria) and then copy,
: or sort the source rectangles and do them in "the right order". Setting
: aside some space inside the rectangle struct for this sorting may provide
: helpful.
:
: This is fairly complicated, but I think (3) is quite doable. I'm worried
: about (1) and (2) as I don't know the clipping/rectangle code too well,
: and it may have to be changed, possibly drastically (for 2).
: Note that (2) is not only for painting in the background color, but for
: creating optimized expose events as well (if we decide to do this).
:
: OK, let me what you think.
:
: Regards,
: Morten Rolland, Screen Media
:
