On Fri, 18 Nov 2011 10:53:23 -0600
DRC dcomman...@users.sourceforge.net 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,
On Thu, 17 Nov 2011 14:07:53 -0600
DRC dcomman...@users.sourceforge.net 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
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
On Wed, 16 Nov 2011 11:14:30 -0600
DRC dcomman...@users.sourceforge.net 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
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
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 similar
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, auto).
On Tue, 15 Nov 2011 18:36:55 -0600
DRC dcomman...@users.sourceforge.net 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
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 my
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
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
11 matches
Mail list logo
