On Dec 28, 2011, at 10:22 AM, Peter Åstrand <astr...@cendio.se> wrote:
> On Wed, 28 Dec 2011, DRC wrote:
>
>
> I'm pretty sure the message from Pierre was that it's not important enough to
> block a new release; not that "we have a solution that fits both use cases
> optimally".
>
> We might solve the -DeferUpdate problem, but as long as the
> VirtualGL/TurboVNC standpoint is "no compromise at all", "any CPU increase is
> a no-no" etc, there will be tons of issues on which we cannot find solutions
> that are optimal for both cases. Without room for compromises and tradeoffs,
> it's an impossible goal.
"Compromise" doesn't mean you always get your way and DRC always gets shouted
down. We compromised on the compression level. I conceded re-enabling the CUT
on CL 2 and above and making CL 2 the default as long as there was an easy way
to get back the Turbo behavior without restarting the server. However, the data
supporting your case was, in my opinion, still weak there as well. It was based
on quick & dirty benchmarks of two apps. That doesn't quite measure up to my
lengthy reports that are the culmination of hundreds of hours of research.
I refuse to be vilified for wanting to maintain the same levels of performance
for 3D and video apps as TurboVNC. These apps are more performance-critical
than Firefox and OpenOffice. But I'm also quite willing to try to find a
solution they satisfies both types of apps. I have done this before, as one of
the afore-mentioned lengthy reports describes. But you seem so insistent that
there is no solution and you'd rather edge me out of the project than try to
find one.
> Having a special script for the ultimate-performance-on-LAN-case would
> be an easy solution.
Let's be clear. The difference between DeferUpdate=1 and DeferUpdate=10 is 30%,
enough to effectively erase all of the hard-fought performance gains since 1.1.
The performance drop affects not just LAN performance but WAN performance.
My basic points all along have been that:
(a) If you and Cendio have apps that you care more about than the ones I have
extensively tested, then you need to develop your own low-level datasets and
quantify the performance under those apps in the same way that I have for the
apps I care about. Simply arguing vague points like "we can't favor LAN
performance over WAN performance" or "we can't favor 3D performance over 2D
performance" is useless unless you have established quantitatively that we have
to favor one over the other, but you haven't. There are knobs that can be
adjusted at the low level that make quite a difference with specific apps, and
sometimes those knobs can be adjusted without affecting other apps too severely.
(b) Never did I say that I am unwilling to compromise, but what I am unwilling
to do is completely write VirtualGL users out of the picture. My only demand is
that there is a Turbo-equivalent mode that is client-side configurable. If we
start getting into such esoteric stuff as having separate launcher scripts,
then why wouldn't I just create a completely different build procedure that
gives me all the defaults I want? Or better yet, why wouldn't I just fork the
project so I wouldn't have to deal with your grief anymore?
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
