nanogui: revamping Blit() to work in portrait mode.
Subject:
Re: [nanogui] revamping Blit() to work in portrait mode.
From:
"Greg Haerr" ####@####.####
Date:
27 Jul 2001 20:27:48 -0000
Message-Id: <014c01c116db$d6d162e0$6817dbd0@censoft.com>
: Let's say that I want to blit an image to the screen in portrait mode --
: should we have the user make an offscreen image (GrNewPixmap) and somehow
: have him place it sideways, or store all images in canonical coordinates,
: and have the Blit be smart enough to do a non-sequential mem-move()?
: Would the approach of having the driver do this last second be too slow?
This one area is the reason I have not yet released 0.89pre8. As it
turns out, the Microwindows engine does not yet handle portrait mode
fully, it will crash when blitting if running in portrait mode in certain
cases. Following is the explanation and proposed design:
In the currently released implementation, Microwindows has a
compile-time option to set portrait mode, and a subdriver is inserted
before the actual framebuffer driver that "rotates" x and y coordinates
before passing them to the original driver, which then draws using
swapped x and y coordinates. This coordinate swapping is also
performed for the driver blit entry point, but the blitting itself is
still performed according to the hardware-view of the framebuffer.
In order to make this simple fix work, the current implementation
stores offscreen pixmaps in hardware, rather than logical orientation.
This allows offscreen pixmaps to be blitted without conversion.
In the new version (CVS, pre9), I have added automatic portrait
mode capabilities that allow the server to reorient all graphics to
a specified (left, right, up and also down) portrait mode without
shutting down, nor restarting any applications. This means that
offscreen pixmaps may need to be re-rotated to use blits at
full speed, or risk having to draw them point-by-point. I have
decided that running blits at full speed is the only solution (we currently
see some of the point-by-point slowness in some of the image decode/
rendering code for instance). This means that offscreen pixmaps
need to be rotated before blitting when the server orientation changes.
This then means that we need conversion rotate blitters for
1, 2, 4, 8, 16, 24 and 32 bpp, and I haven't had time to write them.
My current idea is that each PSD (including the physical PSD)
will maintain an orientation flag, and that offscreen pixmaps
will only be rotated once (to the hardware [phys driver orientation)
only once, and only when needed to, rather than every time the
orientation changes.
Another idea was to discard server pixmaps and have the application
recreate them, but this causes application programming difficulties and
is currently not a good option.
So - to recap and answer Daves' question: - all images will be stored
in canonical coordinates, at least from the perspective of the applications
programmer. Then, when blitting is required, they will be rotated
once only, and then blitted at full speed, without the need for adding
tons of new entry points for each blit rotation in the low-level driver.
This once-only rotation also solves a huge problem when I finally
get the alpha- and transparent-blit driver entry points going, since we
won't need multiple versions of them also.
Regards,
Greg
