http://dev.w3.org/csswg/css3-images/#image-rendering defines the image-rendering property and a new value 'optimize-contrast' to use for image like data where a nearest-neighbor style scaling is desirable. This is similar to the -moz-crisp-edges value that firefox exposes (https://developer.mozilla.org/en/css/image-rendering). Implementing this would be a big performance and quality improvements for pages like the GameBoy emulator in the URL field - that page scales the <canvas> element in CSS. Currently we waste a lot of CPU doing a bilinear filter for the upscale and as a result the pixels look blurry.
There was a bit of controversy in the working group about the name for the optimize-contrast value, so I think we should vendor-prefix the optimize-contrast value for now. The image-rendering property already exists for SVG content and so we don't need to prefix that.

FYI I think the actual rendering changes here are trivial but I'm hoping someone else can take a look at the css parsing/property list stuff since SVGCSSPropertyNames.in scares me. I also suspect there are some other bugs on file about this (40881 looks related) but couldn't find them all through searches.

Attachment 89165[details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/css3..." exit_code: 1
Source/WebCore/rendering/style/RenderStyle.cpp:553: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4]
Total errors found: 1 in 25 files
If any of these errors are false positives, please file a bug against check-webkit-style.

Here is a first cut at this patch. Would like some feedback on the rendering side of things:
- I'm a bit hesitant to rely on the 'lowQualityScaling' param to drawImage - it does what I want, but it doesn't feel like what I mean. I can replace this bool with the InterpolationQuality enum, using 'InterpolationDefault' to mean 'don't change the currently set interpolation', the same as useLowQualityScale=false does now (I'd do this as a separate pre-cleanup patch if so).
- Have I hooked into the right place with the ImageQualityController::shouldPaintAtLowQuality function?
btw - the style failing is because most of RenderStyle.cpp has the boolean operator on the right, so I left it like that.

Comment on attachment 89165[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=89165&action=review
License header is wrong (sent you an email with directions for what the right header for Googlers is), but otherwise I think this looks good.
As for useLowQualityScale, I think a better option would be to have an enum with the default value being "auto" to indicate that the paint() implementation is supposed to figure out the scaling algorithm to use and all non-default values will explicitly specify a scale (either nearestneighbor/bilinear/awesome or some other axis).
> LayoutTests/css3/images/optimize-contrast-canvas.html:23
> +<script>
> + var canvas;
layoutTestController.dumpAsText(true); please - that way it'll generate a .png but no render tree. That should help make the expectations more cross-platform.

Scaling with bilinear in chrome in fullscreen is slow with approx. maximum fps at around 20. When implementing a nearest-neighbor scaling algorithm purely in JavaScript, I can get the same fps rate, so something is seriously wrong here with this picture. This gives more reason to optimize-contrast thankfully.

@jamesr - thanks for the header and dumpAsText(true) comments - I've addressed those.
I've filed https://bugs.webkit.org/show_bug.cgi?id=58495 to track the useLowQualityScale->enum change, as it's orthogonal to this one (smaller patches and all :) ). Once that goes in, I'll reupload this one.

Previous patch failed to land because of a failing SVG CSS test. A simple rebaseline was all that was needed. "run-webkit-tests LayoutTests/css* LayoutTests/fast/css* LayoutTests/svg/css/" now all passes.

Comment on attachment 94506[details]
Patch
Assuming your'e just fixing the no-svg build, OK. Chromium should have a no-svg builder on build.webkit.org if they expect the no-SVG build to work. We've strongly considered disabling that option entirely (making SVG always on).

(In reply to comment #31)
> Why was scaling still slow when the last patch was applied and nearest-neighbor was seen being applied as the rendering algorithm? It felt only marginally better than the normal scaling algorithm.
Did you measure it exactly, or can you construct a test page where we can measure the scale time exactly? I would expect this to speed up the scaling.

Jamesr: Something is holding up the entire JS thread when scaling is done. I'm not even seeing full CPU usage when it slows down, it just seems like webkit is delaying the system timers by doing something weird. For a 160x144 canvas being scaled via nearest-neighbor, it shouldn't slow down to 10 fps when it's scaled up to 400x300 by the fast nearest-neighbor algorithm. Something seriously "gnarly" is going on for sure.
WebKit Nightly for Mac OS X (On Snow Leopard 10.6.7)
Version 5.0.5 (6533.21.1, r87175)
URL listed for this bug still is slow on scaling up the canvas (I can see nearest-neighbor is being applied too now). There definitely seems to be something hanging up the timing.