On 2 Dec 2009, at 3:00 am, Sam Watkins wrote:
Ethan Grammatikidis wrote:
I've had responsiveness issues when the viewing machine hasn't
enough CPU
power to decode the screen data in real-time. A lot of power
seems to be
needed, my PDA, a 416MHz ARM can't cope with any compression at
all, I have
to limit vncviewer to copyrect and raw encodings only.
The Java tightvnc client works fine on my little eee pc, so I would
think the
native client should run well enough on a toaster. Maybe it uses
floating
point and the ARM pda in question doesn't have hardware floating
point.
Sam
Java sometimes does turn up trumps where C code struggles on machines
which were recently considered powerful. Other examples would be web
browsing and Flash video. Now the web supports alternative style
sheets to present a simpler layout on mobile devices and Flash
supports a supports a video format which takes less work to decode -
YouTube offers it as an option. Perhaps the Java TightVNC client
declines the trickier encodings, exactly as I have to pass options to
the C client to do. By default the C TightVNC and RealVNC clients
assume "we can has cycles," which leaves me wondering quite what
situations have sufficient computing power with such measly bandwidth
as to make the 'heavy' encodings worthwhile.
Sorry for the late reply, had to ignore email to get other things in
order.
--
freedesktop.org, because unix doesn't make things harder enough.
Ethan Grammatikidis
eeke...@fastmail.fm
