From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <55909.128.107.253.38.1112163591.squirrel@www.infernopark.com> In-Reply-To: References: <88b16c59972106f2786f8a887e7ddc49@comcast.net><45303.128.107.253.38.1112161613.squirrel@www.infernopark.com> Date: Wed, 30 Mar 2005 00:19:51 -0600 Subject: Re: [9fans] Drawterm Performance on Different OSes From: vdharani@infernopark.com To: "Russ Cox" , "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Cc: Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 2e297136-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. thanks for the details. i used to assume the relationship between drawter= m 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