From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200006261632.MAA13805@cse.psu.edu>
From: "Russ Cox" <rsc@plan9.bell-labs.com>
Date: Mon, 26 Jun 2000 12:32:13 -0400
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 'page' bottom-top turning troubles
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: cab13460-eac8-11e9-9e20-41e7f4b1d025

Typing 'u' in page causes the whole system
to freeze while it does the rotation; it will
come back once the rotation has happened.

There are a number of problems here, most of
them my fault.  First, page is using the
draw(3) driver to do the actual rotation.
It uses O(log Dx+log Dy) draw operations
to make the driver rotate the image in
memory, rather than sucking down all the
bits, performing the operation itself, and
sending them back.  This was a big win for
previewing bitmaps over remote lines when
I wrote that code, and it still is, usually.

The draw driver is single-threaded, mainly
to avoid deadlock when trying to acquire
exclusive access to the images in question,
or the underlying data structures.  Combine
this with the fact that calls to the draw
driver are buffered by libdraw, so that page
queues up its entire list of commands and
sends them in one big swoop to the driver.
Now the driver sits and rotates the image,
doing nothing else until it is done.

This would not be a problem except that
the draw operator is very hard to implement
efficiently for the general case.  The strategy
then was to get a decent general case and
have code that handles most of the common
cases very efficiently.  Copying >= 8-bit
images around via boolean masks was special
cased, but copying < 8-bit images via boolean
masks was not, so you're getting hit by the
general case code for what is quite a lot
of computation.  If you view an 8-bit image
or a true color image, u is much much faster.

When someone else noticed this problem a
while ago, I started to write the special
code for exactly the case you are running
into, and I got disgusted by the fact that
we constantly had to do this.  That's why
I started the on-the-fly x86 compiler to
see how much of a win there was to be had
in getting reasonable code without the hugeness
of all the special cases.  I had also hoped
that the second pass through implementing
the draw operator might lend some insights
toward doing a portable one in a more efficient
manner.  As I said a couple weeks ago, I
stopped working on the code generator version
at some point and never got back to it.
So typing u is still embarrassingly slow
on < 8-bit images.

So that's the cause; the only quick solution
at present is to view a higher-depth image.

Russ