9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] new versions of graphics programs?
@ 2000-09-07 16:08 Anthony Sorace
  0 siblings, 0 replies; 25+ messages in thread
From: Anthony Sorace @ 2000-09-07 16:08 UTC (permalink / raw)


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;




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-07 21:57 rob pike
       [not found] ` <rob@plan9.bell-labs.com>
  2000-09-07 22:50 ` Jim Choate
  0 siblings, 2 replies; 25+ messages in thread
From: rob pike @ 2000-09-07 21:57 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-08  4:34 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-08  4:34 UTC (permalink / raw)
  To: 9fans

>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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-12 10:01 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-12 10:01 UTC (permalink / raw)
  To: 9fans

>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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-12 13:33 Russ Cox
  0 siblings, 0 replies; 25+ messages in thread
From: Russ Cox @ 2000-09-12 13:33 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-13  1:28 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-13  1:28 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-13  2:51 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-13  2:51 UTC (permalink / raw)
  To: 9fans

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-13  2:55 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-13  2:55 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-13  2:58 Russ Cox
  0 siblings, 0 replies; 25+ messages in thread
From: Russ Cox @ 2000-09-13  2:58 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-13  3:19 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-13  3:19 UTC (permalink / raw)
  To: 9fans

>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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-13  3:32 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-13  3:32 UTC (permalink / raw)
  To: 9fans

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-13  5:55 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-13  5:55 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-14  2:31 okamoto
  2000-09-14  8:14 ` Douglas A. Gwyn
  0 siblings, 1 reply; 25+ messages in thread
From: okamoto @ 2000-09-14  2:31 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-15  1:51 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-15  1:51 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-15  2:03 Russ Cox
  2000-09-15  8:47 ` Douglas A. Gwyn
  2000-09-15  8:47 ` Elliott Hughes
  0 siblings, 2 replies; 25+ messages in thread
From: Russ Cox @ 2000-09-15  2:03 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] new versions of graphics programs?
@ 2000-09-15  2:30 okamoto
  0 siblings, 0 replies; 25+ messages in thread
From: okamoto @ 2000-09-15  2:30 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2000-09-15  8:47 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-07 16:08 [9fans] new versions of graphics programs? Anthony Sorace
2000-09-07 21:57 rob pike
     [not found] ` <rob@plan9.bell-labs.com>
2000-09-07 22:18   ` Tom Duff
2000-09-07 22:50 ` Jim Choate
     [not found]   ` <ravage@einstein.ssz.com>
2000-09-07 22:35     ` Tom Duff
2000-09-07 23:24       ` Jim Choate
2000-09-08 15:28         ` please_no_spam_to_
     [not found]           ` <D.M.Pick@qmw.ac.uk>
2000-09-08 16:43             ` Tom Duff
2000-09-08  4:34 okamoto
2000-09-12 10:01 okamoto
2000-09-12 13:33 Russ Cox
2000-09-13  1:28 okamoto
2000-09-13  2:51 okamoto
2000-09-13  2:55 okamoto
2000-09-13  2:58 Russ Cox
2000-09-13  3:19 okamoto
2000-09-13  3:32 okamoto
2000-09-13  5:55 okamoto
2000-09-14  2:31 okamoto
2000-09-14  8:14 ` Douglas A. Gwyn
2000-09-15  1:51 okamoto
2000-09-15  2:03 Russ Cox
2000-09-15  8:47 ` Douglas A. Gwyn
2000-09-15  8:47 ` Elliott Hughes
2000-09-15  2:30 okamoto

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).