Re: [css-images] image-rendering: pixelated, scaling up/down?

On Tue, Sep 23, 2014 at 3:52 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
> On 09/23/2014 03:26 PM, Tab Atkins Jr. wrote:
>> Nope, that's it.  The point of the keyword is to capture an intent,
>> and downscaling with nearest-neighbor doesn't actually do that, so I
>> had it instead do a higher-quality downscale.
>>
>> That said, I'm not too concerned about this.  If it's a bother to
>> track upscaling vs downscaling, I'm fine with just making it
>> consistent.
>
> Thanks!
>
> Since you offered... I have to say, it is somewhat of a bother. :) in
> Gecko, in the function[1] that we converts "image-rendering" into an
> enum that represents a specific scaling algorithm, we don't have access
> to the intrinsic size or render size, so we can't correctly resolve
> "pixelated" there.  (Many callers of that function don't necessarily
> have access to these sizes, either.)
>
> To support the distinct upscaling/downscaling behavior, we'd probably
> have to add a new dummy "pixelated" enum to our list of scaling
> algorithms, and then add special cases to handle it in the code that
> deals with this enum type.  This is all definitely possible, but simply
> treating "pixelated" as "nearest-neighbor" would be much simpler.
>
> Also, the initial Blink implementation of "pixelated" had trouble with
> tracking upscaling vs. downscaling, too -- it didn't pixelate when it
> should've, in a case with HiDPI monitors[1].  So, they needed special
> cases as well, and those special-cases were non-trivial to get right.
>
> So unless there's a strong reason for the upscaling/downscaling
> distinction, I'd support changing the spec to make it consistent.

Done.

~TJ

Received on Tuesday, 23 September 2014 22:56:40 UTC