W3C home > Mailing lists > Public > www-style@w3.org > September 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Sep 2014 15:55:53 -0700
Message-ID: <CAAWBYDDjp=O+f3=HbFvk3y5=-Gp86hAHKY=jaAr5C4_rH6mQtg@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: www-style list <www-style@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:46 UTC