On 9/12/11 7:25 AM, Pierre Ossman wrote:
> Your analysis mentioned that the compression levels also affected
> the sub-rectangle logic, and it wasn't entirely clear to me how
> important that knob was.
Not anymore they don't. In prior versions of TigerVNC, they did.
The analysis clearly shows, h
On Wed, 07 Sep 2011 11:52:09 -0500
DRC wrote:
>
> Hi, Pierre. You may have missed that part of my analysis, but levels
> above 6 are equally as useless on older TigerVNC versions, as well as
> TightVNC (and TurboVNC doesn't use anything above level 1.)
>
Your analysis mentioned that the compr
On 9/7/11 7:54 AM, Pierre Ossman wrote:
>> The viewer GUI has also been modified to reflect the findings from the
>> low-level performance study (specifically, that compression levels
>> higher than 3 rarely have any benefit and compression levels higher than
>> 6 never do. Also, compression level
On 09/07/2011 08:54 AM, Pierre Ossman wrote:
On Wed, 17 Aug 2011 01:40:48 -0500
DRC wrote:
As of now, with the ComparingUpdateTracker disabled and using our FLTK
viewer, the performance is at about 85-90% of TurboVNC at the high
levels, and the rema
On Wed, 17 Aug 2011 01:40:48 -0500
DRC wrote:
> As of now, with the ComparingUpdateTracker disabled and using our FLTK
> viewer, the performance is at about 85-90% of TurboVNC at the high
> levels, and the remaining gap is entirely due to the viewer. The server
> CPU usage is now almost exactly
OK, I'm an idiot. The TigerVNC Server with the ComparingUpdateTracker
disabled was not generating twice the data when the TurboVNC Viewer
connected. I had simply forgotten the way that TurboVNC maps its 1-100
quality scale to TigerVNC's 1-9 quality scale, so in fact I was
comparing JPEG quality 9
Under sponsorship by Cendio, I have completed an extensive (as in 100+
hours) set of performance optimizations to the TigerVNC Server in trunk,
which should bring its performance completely in line with TurboVNC,
provided that the ComparingUpdateTracker is disabled. I am
investigating the afore-me
