Re: [9fans] new versions of graphics programs?

Re: [9fans] new versions of graphics programs?

[Russ Cox]

Your English is fine -- the second pair of
numbers in the header is also one more than the
x and y coordinates of the last pixel, so 
the image is 227x149 not 228x150.  Put another
way, 227 149 is the first pixel just outside
the image in both directions.

Russ

Re: [9fans] new versions of graphics programs?

[okamoto]

Thanks Russ.

>The layers don't (yet) know about
>translucent layers, so that won't
>work just yet.

I can wait it.  We can make many parts for our project while
we are waiting accomplishment of your work.

Kenji

Re: [9fans] new versions of graphics programs?

[Russ Cox]

The layers don't (yet) know about
translucent layers, so that won't
work just yet.

I admit to not understanding the
appeal of double-buffering, especially
the claim that it is more efficient.
You're doing twice the work in twice
the space, because the video card 
manufacturers are skimping on good
double-ported memories.  To me, it
seems like a software solution to a
hardware problem.  Someone set me
straight.

Russ

Re: [9fans] new versions of graphics programs?

[Douglas A. Gwyn]

Russ Cox wrote:
> Someone set me straight.

The idea is to obtain perfect visual effect.
If you have ever "rubber-banded" on a bitmap display
where the rubber-banding was done via XORing,
you must have seen that it was hardest to make out the
object being manipulated just when the finest control
was needed (slow, small movements).
And if you have ever seen single-buffered animation
running wide open, you must have seen the visual
artifacts of beating with refresh rate, or when
VBL sync was used, suddenly exceeding the frame time.
What one wants ideally is the effect of a genuine
stroke-refresh display, using raster technology.
If you can do that without double-buffering, good.

Re: [9fans] new versions of graphics programs?

[Elliott Hughes]

"Russ Cox" <rsc@plan9.bell-labs.com> wrote in message
news:20000915020412.AA23219A01@mail...
> I admit to not understanding the
> appeal of double-buffering, especially
> the claim that it is more efficient.

it's not really an efficiency thing, but it does help make your program look
more snappy. the usefulness of double-buffering is that you don't get caught
with your pants down: the user will never see a half-finished display. as
you say, there's more work to be done, but the point is that you're making
the deadline easier to meet. you don't have to synchronize yourself with the
screen refresh and you don't have to get your drawing done before the next
refresh.

the interesting question is where to do the double-buffering, at what
granularity. if you have a container, is it worth double-buffering each of
its sub-components separately if they're only going to be 'drawn' into the
double-buffered parent? is it worth working out whether you need
double-buffering on a particular repaint? do you end up deciding you may as
well have one buffer per top-level window and do all your drawing into that?

last time i looked at GTK+, which i admit was a while ago, it wasn't using
double-buffering, and it looked terrible. particularly with a window manager
supporting opaque reshaping (i.e. the window changes all the time, rather
than making you guess from a rubber-band outline whether it would now look
the way you want, were you to stop rubber-banding). i haven't seen such
flicker in a long time. it doesn't matter how efficient your repainting is,
you're almost certain to look spastic if you don't double-buffer.

> To me, it
> seems like a software solution to a
> hardware problem.

you can say that about anything. this trade-off is ever-present. but until
all hardware is able to remove the need for double-buffering,
double-buffering is very useful indeed.

double-buffering may seem a waste of time, but speaking as a pragmatist, i
know i wouldn't want to live without it. (nor even do it myself; i'd rather
have it done for me, as it is in Java.)

 - Elliott

Re: [9fans] new versions of graphics programs?

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

doule-buffer..., it may get much speed performance.

I've been thinking of another possiblity to use Plan 9's layer and
transparent color to implement this.  However, I have not
so rigid knowledge of using "windowed" layer yet.  <sigh>

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2389 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] new versions of graphics programs?
Date: Thu, 14 Sep 2000 08:14:05 GMT
Message-ID: <39C053B0.34E4007F@null.net>

okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I wanted to delete the older rect. or
> circle without affecting the background image around it.

The standard solution is to double-buffer the display,
computing a totally fresh image in the new buffer.
Then you can either switch the display to that buffer
or else copy the changed bits to the single frame buffer.
I don't know how feasible this is under the new Plan 9
graphics model.
An alternative approach with modern PC graphics cards
is to build a (3D) model in the graphics card and let
the card's engines take care of the rendering.

Re: [9fans] new versions of graphics programs?

[okamoto]

When I converted art to release 3, I had a problem to implement
rubber-banding to draw rectangular, circle etc. by expanding
or shrinking it by mouse.  I wanted to delete the older rect. or
circle without affecting the background image around it.
I solved it by redrawing all the rectanglar area.

Is there any method to do this fine?

Kenji

Re: [9fans] new versions of graphics programs?

[Douglas A. Gwyn]

okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I wanted to delete the older rect. or
> circle without affecting the background image around it.

The standard solution is to double-buffer the display,
computing a totally fresh image in the new buffer.
Then you can either switch the display to that buffer
or else copy the changed bits to the single frame buffer.
I don't know how feasible this is under the new Plan 9
graphics model.
An alternative approach with modern PC graphics cards
is to build a (3D) model in the graphics card and let
the card's engines take care of the rendering.

Re: [9fans] new versions of graphics programs?

[okamoto]

I placed art.diff to our web page 
(http://basalt.cias.osakafu-u.ac.jp/plan9/p9index.html)
which is written in UTF-8.

This diff is to the Release 2 CDROM distribution.

Kenji

Re: [9fans] new versions of graphics programs?

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 64 bytes --]

This is the correct version of colored art program.

Kenji


[-- Attachment #2: art.pic --]
[-- Type: application/octet-stream, Size: 50407 bytes --]

Re: [9fans] new versions of graphics programs?

[okamoto]

>Aside from creation, there is no way to do things
>like fill a bitmap with a partially transparent
>color.  And so on.  

This was really neccessary to implement anchormark or caret mark
in art program.  I had to solve this by just redrawing all the
acreen, which makes big time loss.

Kenji

Re: [9fans] new versions of graphics programs?

[Russ Cox]

It's hard to know which one is really right.
We decided that the most common use of DTransparent
was when allocating bitmaps, so it should be 0x00000000
(that is, the alpha channel should be 0, indicating
that the pixels are completely see-through).
This means that the transparent pixels, once put
into an image, have no effect when doing other
draw operations with those images.  Hence the comment
	DTransparent	= 0x00000000,		/* only useful for allocimage, memfillcolor */

We used to use 0x000000FF (that is, an alpha channel
of 255, indicating that the pixels are completely
opaque).  The reason for this was that then if you
were trying to create or manipulate masks, you'd want
the "transparent" color to have some substance to it,
so it could be copied from place to place (see for 
example /sys/src/cmd/page/rotate.c).  Thus I gave it
a solid alpha.

When you are creating images without an alpha 
channel, the lack of an alpha channel means the
distinction is lost (indeed, this is why
page/rotate.c still works with DTransparent = 0).

DTransparent really should be 0, so that when you
create an image filled with DTransparent and then draw
it on top of another image, nothing happens.
Before, you'd have blacked out the whole image.

This minor error hints at a bigger problems.  
Aside from creation, there is no way to do things
like fill a bitmap with a partially transparent
color.  And so on.  This is because the draw operator only
uses the Porter-Duff "over" operator.  I'm starting
to rework some of these things, and it looks like
being able to specify the operator as an argument
to gendraw will solve this and other problems.

Russ

Re: [9fans] new versions of graphics programs?

[okamoto]

Color mapping is wrong in the previous image, which was
caused during converting raw pic file -> ppm -> compressed
pic file.   Flower should be red, of course.

Kenji

Re: [9fans] new versions of graphics programs?

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 72 bytes --]

Attached is an example of color version of art program. ^_^

Kenji


[-- Attachment #2: art.pic --]
[-- Type: application/octet-stream, Size: 50407 bytes --]

Re: [9fans] new versions of graphics programs?

[okamoto]

Thanks Russ.

I have one more question on the pre-defined color model of
DTransparent.

In the draw.h file, it is defined as 0x00000000, but as 0x000000FF
in the allocimage(2) manual page (yeah! I got a printed manual
which is very nice to read through).   

I used this transparent color to be transparent over the background 
color.  However, it worked like black as shown in the manual.
Which is right here?  (I wanted to make a moving mark symbol.)

Kenji

Re: [9fans] new versions of graphics programs?

[okamoto]

>I'm not doing this, but am now converting art program to release 3.

I think I have done it without reading pic file for the background
image for art.   In this point, I have a question on the format of
PIC image(6).

I converted flower.jpg file to pic file by jpg(1) with 'c' option.  
The flower.pic file's content is as follows:

compressed
	m8	0	0	227	149	
45	5941 ....compressed data....
80	5897 ....compressed data....
119	5961 ....compressed data....
149	3732 ....compressed data....

The number of the last row should be 150, because the manual
says "The first number is one more than the y coordinate of the 
last row in the block"...

Am I doing anything wrong to understand the English?

Kenji

Re: [9fans] new versions of graphics programs?

[okamoto]

>tools, previously contained in /bin/fb (i think... that's from

I'm not doing this, but am now converting art program to release 3.
This is because we are neccessary to show an example to our
students how to write Plan9 graphic programs...  Art program
uses only native libg library, and it's nice as such an example.

Yes, of course I know, Russ's mixer.c click.c etc, however, those are
too small to show many aspects of programming.  And of course
rio is too difficult to understand for a beginner students.

By the way, is there any example of non-event driven style client
program?

Kenji

Re: [9fans] new versions of graphics programs?

[rob pike]

I started on a couple of the tools.  Since the PIC format is
now largely irrelevant - the standard image format captures
much of its capabilities - it seemed worth retiring the fb
software.  Retiring it also helped keep the distribution smaller
and easier to assemble.  But clearly, some of the tools in 
fb/ are worth having.

I worked on a couple of the tools and stumbled into original
bugs that I didn't see how to fix, so that project has stalled.
The shipped gif and jpg tools and the iconv program should
address some of the lower-level needs.  Higher-level
image processing is a project for a dedicated soul; it's a big
job.

-rob

Re: [9fans] new versions of graphics programs?

[Tom Duff]

> I worked on a couple of the tools and stumbled into original
> bugs that I didn't see how to fix, so that project has stalled.
> The shipped gif and jpg tools and the iconv program should
> address some of the lower-level needs.  Higher-level
> image processing is a project for a dedicated soul; it's a big
> job.

Obviously, I should speak up.  I'm the original author of most
of the fb code, and would be an obvious candidate to revive it
all.  There may be issues with my current employer that I have
to resolve.  I'll take a look at the issues and the code and see
what I might do.  Please speak to me if you have a specific
interest...

-- 
Tom Duff.  Simple PCs with super overcloaked pentiums.

Re: [9fans] new versions of graphics programs?

[Jim Choate]

Speaking of new versions of graphics. Anyone remember NAPLPS?

    ____________________________________________________________________

                     He is able who thinks he is able.

                                           Buddha

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] new versions of graphics programs?

[Tom Duff]

> Speaking of new versions of graphics. Anyone remember NAPLPS?
Get thee behind me, Satan!


-- 
Tom Duff.  Simple PCs with super overcloaked pentiums.

Re: [9fans] new versions of graphics programs?

[Jim Choate]

On Thu, 7 Sep 2000, Tom Duff wrote:

> > Speaking of new versions of graphics. Anyone remember NAPLPS?
> Get thee behind me, Satan!

You're jealous you didn't think of it sooner...

    ____________________________________________________________________

                     He is able who thinks he is able.

                                           Buddha

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] new versions of graphics programs?

[please_no_spam_to_]

Jim Choate (ravage@einstein.ssz.com) wrote:

: On Thu, 7 Sep 2000, Tom Duff wrote:

: > > Speaking of new versions of graphics. Anyone remember NAPLPS?
: > Get thee behind me, Satan!

: You're jealous you didn't think of it sooner...

I was certainly jealous at the time: there were some quite nice ideas in
NAPLPS; especially the coordinate system. Since then I've realised that
if I *had* invented it I would have had to face the prospect of yet another
of my brilliant ideas being undervalued. By the way, can I interest you
in my new mousetrap...

-- 
	David Pick

Re: [9fans] new versions of graphics programs?

[Tom Duff]

Jim Choate (ravage@einstein.ssz.com) wrote:
>
> Thu, 7 Sep 2000, Tom Duff wrote:
>
> > > Speaking of new versions of graphics. Anyone remember NAPLPS?
> > Get thee behind me, Satan!
>
> You're jealous you didn't think of it sooner...

I'm sorry, I didn't understand this until
just now...

I wasn't trying to suggest that NAPLPS was
inferior to the alternatives (Prestel or
Ceefax or whatever), but that the whole idea
of transmitting cheezy little display lists
over ISDN or in your TV's vertical interval
was dopey.  (But, if you have to do that
sort of thing, Display Postscript is more
like the right way to do it.)

-- 
Tom Duff.  Superficial similarities spawn spurious statements.

[9fans] new versions of graphics programs?

[Anthony Sorace]

i'm wondering if anyone at the Labs (or anywhere else, for that
matter) is working on updated versions of the image manipulation
tools, previously contained in /bin/fb (i think... that's from
memory). i know we've got tools to view most images, but i miss
things like pcp, mugs, the filters, rotate, art... even logo.

not to mention /bin/games...
: anothy;