[9fans] point2rgb and point2rgba

[9fans] point2rgb and point2rgba

[andrey mirtchovski]

would anyone strongly object adding two routines to query a pixel's
rgba values from an Image*?  i know one can do it going through
Memimage's, but drawing memimages on screen is painful to watch.

here are the prototypes:

point2rgb(Image *, Point, uchar *r, uchar *g, uchar *b)
point2rgb(Image *, Point, uchar *r, uchar *g, uchar *b, uchar *alpha)

s/uchar/int/ if you think it's better...

andrey

Re: [9fans] point2rgb and point2rgba

[andrey mirtchovski]

> point2rgb(Image *, Point, uchar *r, uchar *g, uchar *b)
> point2rgb(Image *, Point, uchar *r, uchar *g, uchar *b, uchar *alpha)

make the second one 'point2rgba' :)

Re: [9fans] point2rgb and point2rgba

[Russ Cox]

> here are the prototypes:
> 
> point2rgb(Image *, Point, uchar *r, uchar *g, uchar *b)
> point2rgb(Image *, Point, uchar *r, uchar *g, uchar *b, uchar *alpha)
> 
> s/uchar/int/ if you think it's better...

i'd just make it

ulong point2rgba(Image*, Point)

but i question the utility.  if you want just one
pixel, fine, but how often does that happen?
you probably want many pixels, in which case
you should use unloadimage anyway.

each call to point2rgba would have to do
multiple 9p transactions with the draw server.
for anything that processes an entire image,
unloadimage is the right way to go.

russ

Re: [9fans] point2rgb and point2rgba

[andrey mirtchovski]

> but i question the utility.  if you want just one
> pixel, fine, but how often does that happen?
> you probably want many pixels, in which case
> you should use unloadimage anyway.
> 

i'm actually going the other way, but loadimage is really slow on
anything remote, i was hoping that querying a single pixel would be
faster and i could go away with the memimage* functions. 

i'll handle chan2rgb conversion locally.

Re: [9fans] point2rgb and point2rgba

[Russ Cox]

> i'm actually going the other way, but loadimage is really slow on
> anything remote, i was hoping that querying a single pixel would be
> faster and i could go away with the memimage* functions.

if you're using Image* functions, you are editing an image
stored on the other end of /dev/draw.  you don't have the bits in memory.

russ

Re: [9fans] point2rgb and point2rgba

[rog]

> if you're using Image* functions, you are editing an image
> stored on the other end of /dev/draw.  you don't have the bits in memory.

i've always thought that it was a pity that when the image memory is
in fact local, that this can't be optimised (e.g.  by providing direct
access to an offscreen bitmap via segattach(2), negotiating the seg
class via /dev/draw).

has anyone thought about doing something like this?
it'd be nice to be able to push pixels really fast.

Re: [9fans] point2rgb and point2rgba

[andrey mirtchovski]

> has anyone thought about doing something like this?
> it'd be nice to be able to push pixels really fast.

i've stumbled upon this many times since the xscreensaver hacks use
pixel mangling routines so much...  i don't know what the right
solution is, except that loadimage is really slow (and it hits you
really bad whenever the display isn't on the same machine as the
program, drawterm for example).  i know aki nyrhinen did some work on
increasing the bulk transfer for loadimage, but that's about it.

point2rgb seemed like the simplest solution (with rgb2point on the
other hand), but i am now convinced it would be, again, painfully slow
on remote displays.

this situation is rarely seen in the real world :)

Re: [9fans] point2rgb and point2rgba

[Russ Cox]

> this situation is rarely seen in the real world :)

drawterm, cpu, remote X? 

if you express what you want to do in terms 
of real draw operations instead of loadimage 
and unloadimage, then you will be much happier.
xscreensaver is slow because you are not using
the system the way it was intended to be used.

russ

Re: [9fans] point2rgb and point2rgba

[andrey mirtchovski]

> xscreensaver is slow because you are not using
> the system the way it was intended to be used.


I agree :)

Re: [9fans] point2rgb and point2rgba

[rog]

> if you express what you want to do in terms 
> of real draw operations instead of loadimage 
> and unloadimage, then you will be much happier.
> xscreensaver is slow because you are not using
> the system the way it was intended to be used.

but the real draw operations are a fairly arbitrary set.  i'd hazard
that most of the xscreensaver graphics output could not be nicely
expressed in terms of real draw operations.

didn't an earlier version of the draw device rely entirely on pushing
bitmaps?  from that perspective, the current draw device is just a
bandwidth optimisation for commonly found graphics operations.

there are applications that really do need to push lots of
custom-generated pixels of data to the screen.  it seems a pity that
this kind of thing is so heavily penalised in plan 9.  maybe it's just
that so many of these kind of applications are basically frivolous
(screensavers and games)...

Re: [9fans] point2rgb and point2rgba

[andrey mirtchovski]

> there are applications that really do need to push lots of
> custom-generated pixels of data to the screen.  it seems a pity that
> this kind of thing is so heavily penalised in plan 9.  maybe it's just
> that so many of these kind of applications are basically frivolous
> (screensavers and games)...

anything opengl is an example of this.  it's nearly impossible to do
opengl for plan9 using libdraw primitives, since converting a ulong to
a color needs to go through allocimage.

i heard someone suggest using an rgb color triangle already
allocimage'd in rio as a source for pre-allocated colors, but try
drawing a replicated pixel sourced from a larger image without a 1x1
intermediary :)

Re: [9fans] point2rgb and point2rgba

[Joel Salomon]

On Mon, 31 Jan 2005 19:19:53 0000, rog@vitanuova.com <rog@vitanuova.com> wrote:
> there are applications that really do need to push lots of
> custom-generated pixels of data to the screen.  it seems a pity that
> this kind of thing is so heavily penalised in plan 9.  maybe it's just
> that so many of these kind of applications are basically frivolous
> (screensavers and games)...
> 
IIRC, the XaoS fractal browser uses some form of double buffering and
whole-screen updates to get decent performance. My guess would be that
for 2-D graphics—even at the high end (like real-time MPEG-2 or MPEG-4
display)—such would be sufficient. Does the current draw device
penalize these operations so much?

--Joel

Re: [9fans] point2rgb and point2rgba

[andrey mirtchovski]

> IIRC, the XaoS fractal browser uses some form of double buffering and
> whole-screen updates to get decent performance. My guess would be that
> for 2-D graphics—even at the high end (like real-time MPEG-2 or MPEG-4
> display)—such would be sufficient. Does the current draw device
> penalize these operations so much?
> 
> --Joel

xaos uses a CMAP8 image to which it loads a bitmap, the image is then
drawn using draw()..

the problem with that is the slowdown is twofold -- once to transfer
the bitmap to draw, then the draw operation itself is slow if the
image has a different channel than the display.

Re: [9fans] point2rgb and point2rgba

[rog]

> Does the current draw device penalize these operations so much?

i believe so.  (particularly if you're doing lots of small scattered
updates to a largish image).

say you've got some software which maintains its own client-side
bitmap.  for each rectangle to be updated, you've got to copy the bits
for that rectangle into a buffer(*), invoke loadimage, which copies the
data into another buffer (with at least 21 extra), invokes a write
syscall (one for each 64K of data), which copies the data into the destination image.

since the display can be in any channel format, and one generally
wants to avoid code bloat, it's not uncommon to have the destination
image actually be an intermediate image in a known pixel format, which
is then actually copied onto an on-screen image.

if you could get the draw device to create an image to which there was
shared-memory access, all but the last step could be eliminated.
i reckon this could speed things up a lot, but i haven't measured it,
so it's quite possible i'm totally misguided.

(*) one way to eliminate one data copy in the above scenario might be to
give loadimage a "skip" argument (a number of bytes in the data to
skip after each line).  then at least you could do loadimage directly
from the client-side image data. this wouldn't affect the anything
if you're always blitting the whole image.