nanogui: Thread: revamping Blit() to work in portrait mode.

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?

-David

On Fri, 27 Jul 2001 04:10:12 -0500 (CDT), David Eger said:

> 
>  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?
>  
>  -David

hi all :)

I don't know about the precise implementation of the current Blit code, but the
low-level speed difference between a sequential and non-sequential move should
be very minimal, by the order of maybe 1 or 2 cycles per pixel, at least on
latest cpu.

Personally I would be considering having the Blit code be smart enough, helps
make this portrait mode handling transparent to applications.
-- 
Bandai Kaosu Jikuu
EKS - Dave Poirier

In terms of making it easier for the programmer, the first approach is always 
the best.  Its really all a question of when you want to actually do the math 
to compute the rotation.  I would rather that the math be computed when I 
draw, and then the blit would be a move of a contigious memory space.

Also, pixmaps are intended to act exactly like onscreen drawables in every 
way.  This makes it easier for the developer since he/she doesn't have to 
change their philosophy when writing offscreen, and it also makes it easier 
on the drawing engine, since the same code (to a certain point) can be used 
on both onscreen and offscreen drawables.

Following this, if I draw a point on the visible screen, we will have to do 
the rotation math anyway, so why should it be any different for the offscreen 
drawable?

Jordan

On Friday 27 July 2001 03:10, David Eger mentioned:
> 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?
>
> -David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

: 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