From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <ee9e417a050329163315aa07d8@mail.gmail.com>
Date: Tue, 29 Mar 2005 19:33:32 -0500
From: Russ Cox <russcox@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Drawterm Performance on Different OSes
In-Reply-To: <45303.128.107.253.38.1112161613.squirrel@www.infernopark.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <88b16c59972106f2786f8a887e7ddc49@comcast.net>
	<45303.128.107.253.38.1112161613.squirrel@www.infernopark.com>
Topicbox-Message-UUID: 2e24ab24-ead0-11e9-9d60-3106f5b1d025

> 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.

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.

russ