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

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.

~Daniel

[1] https://code.google.com/p/chromium/issues/detail?id=391351

Received on Tuesday, 23 September 2014 22:53:05 UTC