Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-21 Thread Pierre Ossman
On Fri, 18 Nov 2011 10:53:23 -0600 DRC wrote: > On 11/18/11 2:45 AM, Pierre Ossman wrote: > >> I think it would be worth it to have on, off, and auto. We always want > >> to offer the user the ability to override our decisions. > > > > I'm not sure about the "always" part, but here's an updated

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-18 Thread DRC
On 11/18/11 2:45 AM, Pierre Ossman wrote: >> I think it would be worth it to have on, off, and auto. We always want >> to offer the user the ability to override our decisions. > > I'm not sure about the "always" part, but here's an updated patch for > compareFB at least. Except for removing the

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-18 Thread Pierre Ossman
On Thu, 17 Nov 2011 14:07:53 -0600 DRC wrote: > I think it would be worth it to have on, off, and auto. We always want > to offer the user the ability to override our decisions. I'm not sure about the "always" part, but here's an updated patch for compareFB at least. Rgds -- Pierre Ossman

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-17 Thread DRC
On 11/17/11 12:43 PM, Pierre Ossman wrote: > Because it's a boolean. It has just the states true or false. There is > no mechanism to see if the user didn't bother specifying anything (and > I'm not sure that's desirable anyway). So we cannot map our three > states to it ("always on", "always off",

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-17 Thread Pierre Ossman
On Thu, 17 Nov 2011 11:57:59 -0600 DRC wrote: > Not sure if I understand why it couldn't be overridden by passing > compareFB=1 on the command prompt to always enable it. > Because it's a boolean. It has just the states true or false. There is no mechanism to see if the user didn't bother speci

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-17 Thread DRC
Not sure if I understand why it couldn't be overridden by passing compareFB=1 on the command prompt to always enable it. On 11/17/11 7:23 AM, Pierre Ossman wrote: > Suggested patch. It does the following: > > - CUT block size changed to 64 pixels. This size in most cases has a > CPU usage simi

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-17 Thread Pierre Ossman
Suggested patch. It does the following: - CUT block size changed to 64 pixels. This size in most cases has a CPU usage similar to 256 pixels, but a coverage more similar to 16 pixels. - Default compression level changed to 2. Based on your numbers, this seems to get us most of the compressi

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-17 Thread Pierre Ossman
On Wed, 16 Nov 2011 11:14:30 -0600 DRC wrote: > On 11/16/11 5:25 AM, Pierre Ossman wrote: > > JPEG quality level 1 is not what I'm considering a reasonable WAN > > setting, so I'm not sure how realistic these numbers are. Still, I > > think my conclusions are roughly the same. > > Well, then, wh

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-17 Thread Peter Åstrand
On Wed, 16 Nov 2011, DRC wrote: We could, but we generally would like not to. We prefer if our goals align with the upstream projects we use. There is less friction when it comes to long term plans that way, and having our users running basically the same product as the project's users benefits

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-16 Thread DRC
On 11/16/11 5:25 AM, Pierre Ossman wrote: > JPEG quality level 1 is not what I'm considering a reasonable WAN > setting, so I'm not sure how realistic these numbers are. Still, I > think my conclusions are roughly the same. Well, then, what are you considering to be appropriate WAN settings? When

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-16 Thread Pierre Ossman
On Wed, 16 Nov 2011 12:25:43 +0100 Pierre Ossman wrote: > > > > Here's what I would recommend for now: > > > > (1) Change BLOCK_SIZE to 256. This didn't seem to have any effect on > > compression ratio, and it improved performance significantly whenever > > the CUT was enabled. Pierre, could

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-16 Thread Pierre Ossman
On Tue, 15 Nov 2011 18:36:55 -0600 DRC wrote: > The attached spreadsheet shows the low-level performance effects of > enabling and disabling the CUT, as well as the effect of changing its > block size to 256 x 256 instead of the default of 16 x 16. Tests were > performed both with typical LAN se

Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-15 Thread Peter Åstrand
The attached spreadsheet shows the low-level performance effects of enabling and disabling the CUT, as well as the effect of changing its block size to 256 x 256 instead of the default of 16 x 16. Tests were Nice work! If Cendio wants the CUT always enabled for their product, then that is

[Tigervnc-devel] Low-level ComparingUpdateTracker performance

2011-11-15 Thread DRC
The attached spreadsheet shows the low-level performance effects of enabling and disabling the CUT, as well as the effect of changing its block size to 256 x 256 instead of the default of 16 x 16. Tests were performed both with typical LAN settings (compress level=1/quality level=8) and WAN settin