[9fans] More about /dev/draw

[Dave MacFarlane <driusan@gmail.com>]

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

Either I'm going insane, the default Plan 9 /dev/draw in-memory
implementation
doesn't implement draw(3), or possibly both.

When I do the following, it works as expected under both drawterm and a
locally mounted instance:
1. Allocate a screen with an 'A' message
2. Allocate an image on the screen of the same size as /dev/wctl  with a
'b' message
3. Draw the image over the window with a 'd' message
4. Flush the buffer with 'v'

When I do the following, it works under drawterm, but not with a local
/dev/draw implementation:
Steps 1-2 above
3. Allocate another image of some arbitrary fill colour with 'b' (with or
without the repl bit)
4a. (Optional, doesn't seem to make a difference) set the compositing
operator with 'O'
4b. Draw the new image over a portion of the window image from step 2 with
'd'
5. Go to step 3-4 from the first variation.

(I don't have a 9front instance to test on.)

On the other hand, replacing a portion of the image from step 2 with 'y'
works under either. (I haven't gotten around to using 'Y' when appropriate
yet.)

Basically, I can only get any variation of this code:
https://github.com/driusan/exp/blob/18a78a1549541d46d26cb6088a904585c386d812/shiny/driver/devdrawdriver/uploadimpl.go#L50

to work under drawterm.

The end result is that under a local Plan 9 instance the basic sample shiny
test looks like this:

http://driusan.github.io/plan9/basicmem.png

Instead of this:

http://driusan.github.io/plan9/basicdrawterm.png

Does anyone have any pointers? I don't have much access to a physical Plan
9 machine, so I'm having trouble debugging this since it works under
drawterm (or perhaps is buggy under drawterm in a way that makes it seem
like it's working..)

It would also potentially be helpful if someone who uses Go under 9front
could let me know how x/exp/shiny/examples/basic looks with the shiny
driver in that branch, but I'm not sure that it matters since it'll most
likely be the same as one of the above..

- Dave

[-- Attachment #2: Type: text/html, Size: 2805 bytes --]