On Tue, Sep 23, 2014 at 3:52 PM, Daniel Holbert <***@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
> Since you offered... I have to say, it is somewhat of a bother. :) in
> Gecko, in the function 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. 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.