9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Tharaneedharan Vilwanathan" <vdharani@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] rio startup fails in VMWare Fusion 2.0.0
Date: Wed, 24 Dec 2008 04:46:05 -0800	[thread overview]
Message-ID: <dac0a5820812240446p479f5dccv59642ea267035f2d@mail.gmail.com> (raw)
In-Reply-To: <913463a98d5dd438f480d485cfb11f83@terzarima.net>

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

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

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

  reply	other threads:[~2008-12-24 12:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-23 16:08 Gary V. Vaughan
2008-09-23 18:03 ` Federico G. Benavento
2008-09-24  3:25   ` Gary V. Vaughan
2008-09-24  3:30     ` erik quanstrom
2008-11-19  9:53 ` Richard Miller
2008-11-19 11:55   ` Rodolfo kix García 
2008-12-14  8:25     ` Ben Calvert
2008-12-14 12:43       ` erik quanstrom
2008-12-14 23:16         ` Ben Calvert
2008-12-14 23:25         ` Ben Calvert
2008-12-22 11:30           ` Tharaneedharan Vilwanathan
2008-12-22 13:39             ` Richard Miller
2008-12-22 14:32               ` Jeff Sickel
2008-12-23  0:15                 ` Tharaneedharan Vilwanathan
2008-12-23  4:13                   ` Skip Tavakkolian
2008-12-23 11:14                   ` Charles Forsyth
2008-12-24 12:46                     ` Tharaneedharan Vilwanathan [this message]
2008-12-23  0:05               ` Tharaneedharan Vilwanathan
2008-12-23 19:58                 ` Richard Miller
2008-12-24 12:27                   ` Tharaneedharan Vilwanathan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dac0a5820812240446p479f5dccv59642ea267035f2d@mail.gmail.com \
    --to=vdharani@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).