On Thu, 10 Nov 2011 13:40:38 -0600 DRC <dcomman...@users.sourceforge.net> wrote:
> Sorry, but I've quantified the reasons why it should be disabled on a
> LAN. If you see some benefit in performance on a WAN, then you need to
> quantify that as well. I will not endorse TigerVNC unless it is
> "performant by default."
I'm sorry you feel that way as tuned for LANs at the expense of
everything else is not our goal. The defaults should reflect the needs
of the majority of users. We're trying to create a well-rounded VNC
implementation that can be used for a broad range of applications, not
just LAN use.
I'd also like to hear what other people think. Adam? Brian? Anyone else
following this list? What use cases are your priority?
> The CUT uses a significant amount of server CPU time, so if it benefits
> WAN-based scenarios, it needs to be quantified how much and how much of
> a CPU time hit is incurred from the LAN-based scenarios. If it
> benefits only one and not the other, then the default behavior needs
> to be enabling it only when it shows a clear benefit without
> compromising overall frame rate.
Why? I'd argue the opposite. It's should only be disabled when it is
clear that it is the limiting factor. For many (most?) users, that
limiting factor will be bandwidth, not CPU. And there is also the fact
that there is a "good enough" framerate, namely when it is no longer
possible for the user to tell the difference. Bandwidth is generally
always worth reducing.
But you want some numbers, so I did some quick measurements:
Firefox, msn.com, 10 seconds with a blinking cursor and animated
preview:
With comparing:
1.3 MiB to 2.4 MiB
Without comparing:
3.8 MiB to 7.5 MiB
Bandwidth savings:
66-68%
Firefox, idg.se, 10 seconds with an animated GIF banner ad:
With comparing:
420 KiB to 450 KiB
Without comparing:
12 MiB to 16 MiB
Bandwidth savings:
96-97%
Compositing, gnome-terminal, 10 seconds with mostly just empty space
and blinking cursor:
With comparing:
30 KiB
Without comparing:
501 KiB
Bandwidth savings:
94%
Compositing, gnome-terminal, 10 seconds with a fair amount of text
present and blinking cursor:
With comparing:
100 KiB
Without comparing:
1.7 MiB
Bandwidth savings:
96%
These numbers are way too big to ignore. And given that the CUT used to
be enabled (i.e. this is a regression), and that I have yet to see an
installation where server side CPU was such a major issue that
bandwidth can be ignored, I say we should revert to the 1.1.0 behaviour.
More work on the CUT is of course worthwhile. Perhaps it should have
some heuristic on automatically turning it on and off based on the
availability of CPU? But where we stand right now, having it off is a
worse trade-off than having it on. IMO.
Rgds
--
Pierre Ossman OpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB Web: http://www.cendio.com
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
