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",
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
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
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
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
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
