stateless thin cliens with decent graphics performance - possible?

[Piotr Gluszenia Slawinski]

> This is all good and well, but thanks to VNC, the graphics performance
> is horrible, especially on the bigger screens.
> (For example, on my 1600x1200 monitor, I can clearly follow the
> full-screen windows refreshing, which is no big feat, since it takes
> several seconds.)

i use vnc myself, and usually network is the bottleneck.
did you checked what is bottleneck in your case?
if you are using decent thin clients, you could consider using
i.e. tigervnc or other vnc server providing more robust, but
lossy compression (using it myself, and it works pretty nice).

playing with i.e. deferupdate option on server and compresslevel
on client is also worth trying.

main difference from x session seems to be fact that while x session can
i.e. clear screen with single command sent over network, it means sending 
whole screen data with vnc.

similiar issue occurs with remote X session. even though your app might be 
full-screen, it could modify on-screen contents using much smaller 
commands sent via tcp/ip, which may bring larger effect (i.e. text 
scrolling up/down), while vnc has to send whole data instead.

quite good 'benchmark' of vnc vs plain X seems to be 'xaos', as it
just sends whole 'result' of it's calculations to client as plain image 
buffer.

  set it to'continous rotation' (press 'o' and select it).
once started, 
check cpu usages, and network usages, irq
load, etc. try to compare performance via vnc with various levels
of compression and deferupdate setting, with 'bare' X session .
try various sizes, and see how quickly performance drops once network
saturates :)

i've once had idea of using 'lossy' screen update algorithm,
sending just random Nth line, instead of line-after-line method,
assuming next update will occur soon anyway and 'gaps' will be filled.
ofcourse vnc client had to also issue 'full' update if last incomplete 
update of region was not followed by any subsequent update.

such method is succesfully used by many 8-bit demoscene coders to
off-load cpu with i.e. vector graphics effects, as mere copy-to-screen
consumes lot of cpu time, while it seems 'interactivity' has more priority
over loss of some visual information (i.e. it gives more 'eye comfort' 
when object is displayed with 50fps with some data missing, than if it's
displayed with all detail but @ i.e. 10fps)

unfortunatelly to date noone had implemented such method to vnc clients
and servers, and personally i'm too lame to code that :)


greetings 
--