>tested so far, drawterm, 9vx are all so slow in updating inferno screen (i
i tried running inferno in an 1152x900 x8r8g8b8 within 9vx. (the window is controlled by rio in 9vx but even then emu's draw operations go direct to the 9vx kernel via draw.) this is on a 1.2Ghz core duo on ubuntu 8.04. it "didn't seem too bad" (ie, not unusable) but it probably isn't as responsive as under plan 9 proper and if you're used to that you probably would notice the difference. i can't easily run them side by side for direct comparison. inferno applications will be drawing via Inferno's /dev/draw, with a screen implementation that ships updated rectangles to plan 9's using its 'y' and 'v' operations. the buffer size is determined by plan 9's iounit. inferno (on Plan 9 and thus 9vx) can be set to use plan 9's /dev/draw directly, so inferno applications will be bypassing emu's /dev/draw. it's a proof-of-concept scheme (ie, too many limitations at the moment for real use -- not because of draw but window management). i tried my script to run charon that way, under 9vx, and it was much, much worse than under wm through inferno's own draw, so that's not an immediate fix. it was really very bad. (by the way, the only significant reason for inferno's current indirection on plan 9 is to ensure the same draw code is used and tested in all implementations.)
