Graphical programs using Go images and Plan 9 images

[Jeremy Jackins]

I have a Go package whose usage goes something like this:

- Client provides Package with a channel of user input events

- Package provides Client with a channel of Go images

- Client receives images from the channel and draws them onto a window (the user clicked something or pressed a key, so the window must be updated)

In my program, I'm using code.google.com/p/goplan9/draw (hacked to work on native Plan 9) to do the last part. My strategy is to do something like this:

disp.ScreenImage.Load(r, img.Pix)

img.Pix is the pixel data of the Go image, in R,G,B,A order. But depending on where I run the program, the pixel format for the Plan 9 display maybe be x8r8g8b8, x8b8g8r8, etc., so the colors may be wrong. My current solution is to use an intermediate Plan 9 draw.Image that has been created with correct pixel format, and then drawing that to disp.ScreenImage, which does the right thing. But it feels very inefficient (and indeed my program runs very slowly) to do all my drawing using the standard Go draw functions, and then load the data to a Plan 9 image, and then draw that again to the screen image. Is there a better way that I'm missing? I don't want the package to know anything about Plan 9, but dirty hacks are acceptable in the program using the package.

[Nick Owens]

i encourage you to try out http://godoc.org/bitbucket.org/mischief/draw9. it's very poor and basically hacked from rsc's package which you linked. there's a few example programs. another example is https://bitbucket.org/mischief/jerkcity/src/e82aa54a28427514b542b9523898750e4ad987c1/main.go?at=default which is a viewer for the jerkcity comic strip.

really, the changes should be merged to rsc's draw, but there's major differences. mainly, plan9port's devdraw(1) implements a protocol on which the mouse, keyboard, and snarf buffer ride on, as well as the draw protocol. we have no such problem on plan 9, although my package has some mouse and keyboard (cons) support, as well as support for 9front's kbd.

[Jeremy Jackins]

Interesting, thanks for the link. I'll check it out.