nanogui: Area Copies and clipping code
Subject:
Area Copies and clipping code
From:
Morten Rolland ####@####.####
Date:
28 Apr 2000 08:42:28 -0000
Message-Id: <39095ABA.A32B70BE@screenmedia.no>
Hello all,
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
