From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 24 Dec 2008 04:46:05 -0800 From: "Tharaneedharan Vilwanathan" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <913463a98d5dd438f480d485cfb11f83@terzarima.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_103344_32252347.1230122765983" References: <913463a98d5dd438f480d485cfb11f83@terzarima.net> Subject: Re: [9fans] rio startup fails in VMWare Fusion 2.0.0 Topicbox-Message-UUID: 6edcfdb6-ead4-11e9-9d60-3106f5b1d025 ------=_Part_103344_32252347.1230122765983 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hi charles, thanks for the details. 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 yes, in cases like this, it is usable but the noticeable lag and the relatively slow updates make me feel uncomfortable, particularly since i try to use this kind of setup all the time, as opposed to sporadic use. also, i think the issue becomes more severe for higher bits-per-pixel and higher screen resolution, say 1920x1200. btw, i was always happy with the speed at which plan9 updates screen (as much as i like plan9 graphics interface itself). the screen updates are not too fast, not too slow. i used to feel too fast screen updates are not good for good experience (for development at least). i am also happy with the speed at which inferno draw runs on top of plan9 when plan9 runs natively. the cases where i see noticeable differences are like vmware-fusion/parallels, drawterm, remote plan9 terminal over network in which inferno is started, etc. > 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.) > is this something that was introduced in vita nuova's release? from what i remember from inferno BU times, i think inferno used plan9's draw directly since there was (almost?) no difference at that time. thanks dharani ------=_Part_103344_32252347.1230122765983 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hi charles,

thanks for the details.

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
yes, in cases like this, it is usable but the noticeable lag and the relatively slow updates make me feel uncomfortable, particularly since i try to use this kind of setup all the time, as opposed to sporadic use. also, i think the issue becomes more severe for higher bits-per-pixel and higher screen resolution, say 1920x1200.

btw, i was always happy with the speed at which plan9  updates screen (as much as i like plan9 graphics interface itself). the screen updates are not too fast, not too slow. i used to feel too fast screen updates are not good for good experience (for development at least). i am also happy with the speed at which inferno draw runs on top of plan9 when plan9 runs natively. the cases where i see noticeable differences are like vmware-fusion/parallels, drawterm, remote plan9 terminal over network in which inferno is started, etc.


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.)
is this something that was introduced in vita nuova's release? from what i remember from inferno BU times, i think inferno used plan9's draw directly since there was (almost?) no difference at that time.

thanks
dharani

------=_Part_103344_32252347.1230122765983--