[9fans] 'page' bottom-top turning troubles

[9fans] 'page' bottom-top turning troubles

[Wladimir Mutel]

	Greetings,

	At last I read 'man page' and started to see how it works.
	I noticed that whe I press 'u' to turn page bottom-top, rest
	windows get freezed, i.e. by left-clicking on any other window it does
	not become active and topmost. Whole window system except mouse
	cursor gets freezed ! May be I missed something about time-sharing
	in Plan9 ? Please explain the cause and may be give some help .

	Thanks.

--
mwg@alkar.net

Re: [9fans] 'page' bottom-top turning troubles

[Russ Cox]

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

Re: [9fans] 'page' bottom-top turning troubles

[Wladimir Mutel]

Russ Cox <rsc@plan9.bell-labs.com> wrote:

> 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.

	Yes I view in 800x600x8bits mode,
	my videocard is a kind of S3Trio64 (Trio64V2).

> So typing u is still embarrassingly slow
> on < 8-bit images.

	I have exactly 8 bits per pixel. It is 'gs' output viewed by
	'page', hope its depth is not less than 8 ?

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

	Unfortunately my videocard does not seem to work in 16 or more
	bpps, as 'supported hardware' reads.

--
mwg@alkar.net

Re: [9fans] 'page' bottom-top turning troubles

[Eric Dorman]

----- Original Message -----
From: "Wladimir Mutel" <mwg@alkar.net>
To: <9fans@cse.psu.edu>
Sent: Tuesday, June 27, 2000 1:31 AM
Subject: Re: [9fans] 'page' bottom-top turning troubles


> Russ Cox <rsc@plan9.bell-labs.com> wrote:
[stuff]
> Unfortunately my videocard does not seem to work in 16 or more
> bpps, as 'supported hardware' reads.

the Trio64V2 should do 1280x1024x8, 1024x768x16 and 800x600x24
(according to the doc); aux/vga just doesn't support the higher depth modes.
i hope to tackle that one soon.. if you're interested in working on that i
have the S3 docs (open disclosure) or you can get them from S3.

> mwg@alkar.net

regards,

Eric Dorman
edorman@san.rr.com

Re: [9fans] 'page' bottom-top turning troubles

[rsc]

	I have exactly 8 bits per pixel. It is 'gs' output viewed by
	'page', hope its depth is not less than 8 ?

I wasn't talking about the depth of
the screen but the depth of the actual
image, which can be (and often is)
different.

Gs produces a depth as small as possible.
If you like, you could edit /sys/src/cmd/gs/src/gdevifno.c
to always produce 8-bit images; change
	idev->ldepth = 0
to
	idev->ldepth = 3
in inferno_open().

I haven't done that because the right fix is
to get draw correct instead, and because the
driver needs to be updated for the new color
scheme anyway.

Russ