[9fans] Drawterm Performance on Different OSes

[9fans] Drawterm Performance on Different OSes

[Greg Pavelcak]

I have a Dell GX-270 at work, currently running Windows XP. I'm
writing this using drawterm-win to my Plan 9 box at home.  Last week, I
had gotten so fed up with Windows that I installed FreeBSD 5.3 on the
same Dell machine at work and also drawterm-ed home, but it was so
slow as to be unusable.  Any guesses as to why this would be?  Next
time I put FreeBSD on, I'd like to be able to drawterm home.

Thanks.

Greg

Re: [9fans] Drawterm Performance on Different OSes

[Russ Cox]

> I have a Dell GX-270 at work, currently running Windows XP. I'm
> writing this using drawterm-win to my Plan 9 box at home.  Last week, I
> had gotten so fed up with Windows that I installed FreeBSD 5.3 on the
> same Dell machine at work and also drawterm-ed home, but it was so
> slow as to be unusable.  Any guesses as to why this would be?  Next
> time I put FreeBSD on, I'd like to be able to drawterm home.

it sounds like TCP NODELAY is not being turned on,
though i just looked at /sys/src/cmd/unix/drawterm/devip-unix.c
and it sure looks like it tries to turn it on.

russ

Re: [9fans] Drawterm Performance on Different OSes

[andrey mirtchovski]

i use drawterm at 24/32bpp all the time. it's plenty fast. X drawing
is usually not the issue with dt.

Re: [9fans] Drawterm Performance on Different OSes

[Russ Cox]

> 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

Re: [9fans] Drawterm Performance on Different OSes

[vdharani]

hi,

> I have a Dell GX-270 at work, currently running Windows XP. I'm
> writing this using drawterm-win to my Plan 9 box at home.  Last week, I
> had gotten so fed up with Windows that I installed FreeBSD 5.3 on the
> same Dell machine at work and also drawterm-ed home, but it was so
> slow as to be unusable.  Any guesses as to why this would be?  Next
> time I put FreeBSD on, I'd like to be able to drawterm home.

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?

thanks
dharani

Re: [9fans] Drawterm Performance on Different OSes

[vdharani]

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

Re: [9fans] Drawterm Performance on Different OSes

[andrey mirtchovski]

try the undocumented "-b" option which turns off the broken stipple
fix (i.e. the disappearing fonts). that'll speed up dt considerably...

sorry, can't have the cake and eat it too