9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: vdharani@infernopark.com
To: "Russ Cox" <russcox@gmail.com>,
	"Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Drawterm Performance on Different OSes
Date: Wed, 30 Mar 2005 00:19:51 -0600	[thread overview]
Message-ID: <55909.128.107.253.38.1112163591.squirrel@www.infernopark.com> (raw)
In-Reply-To: <ee9e417a050329163315aa07d8@mail.gmail.com>

>> i am thinking if host on which drawterm runs is set to 24bpp or 32bpp,
>> plan9 needs to send bulkier data for screen updates causing the
>> bottleneck. setting it to lower bpp may solve it? or am i wrong?
>
> most applications do not read or write raw images.
> usually images are constructed with sequences of
> draw instructions whose size is mostly depth-independent.
> when sections of images are copied to other images
> (for example, when using overlapping windows in rio),
> all the image data is kept inside drawterm.  the plan 9
> side never sees the raw images.
thanks for the details. i used to assume the relationship between drawterm
entities is similar to the relationship between the host and the graphics
card (intelligent ones).

> if you're running emu or links or something like that,
> then yes you're right.  but for acme, rio, and sam, the
> depth should not matter.
yes, i have seen emu being so slow even when plan9 and drawterm host are
in the same network. once can see the screen getting updated rather
slowly. also, there is one other problem (i think related to the way acme
handles the incoming messages) that charles forsyth mentioned.

thanks
dharani



  reply	other threads:[~2005-03-30  6:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-29 16:49 Greg Pavelcak
2005-03-29 22:03 ` Russ Cox
2005-03-30  5:46 ` vdharani
2005-03-30  0:27   ` andrey mirtchovski
2005-03-30  0:33   ` Russ Cox
2005-03-30  6:19     ` vdharani [this message]
2005-04-04 23:20       ` andrey mirtchovski

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=55909.128.107.253.38.1112163591.squirrel@www.infernopark.com \
    --to=vdharani@infernopark.com \
    --cc=9fans@cse.psu.edu \
    --cc=russcox@gmail.com \
    /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).