This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12044 - Feature request: Give developers an option to disable a context's image smoothing
Summary: Feature request: Give developers an option to disable a context's image smoot...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML Canvas 2D Context (show other bugs)
Version: unspecified
Hardware: All All
: P3 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard: canvas v5
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-12 00:08 UTC by contributor
Modified: 2012-03-28 21:46 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2011-02-12 00:08:25 UTC
Specification: 
Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top

Comment:
This is a new feature request.

Request overview: Give developers an option to disable a context's image
smoothing (ie, anti-assailing).

Problem: When scaling up images, most user agents smooth the output. This is
fine for most use cases, but is undesirable when "pixel-perfect" output is
desired. Unfortunately, there is nothing in the spec that allows a user to
turn off this smoothing. 

I ran into this issue when I was creating a canvas based image editor. In
particular, it more or less torpedoed my first attempt at creating a zoom
feature. Simply put, when I tried to show a "zoomed in" view of a smaller base
image, the "pixels" of the zoomed view were anti-assailed and bled into each
other. The effect was ugly and (more importantly) non-representative of the
actual image being edited, which nicely defeated the purpose of an image
editor. 

Currently the only solution is to roll your own scaling algorithms based on
imageData, which is less than ideal.

Use cases: Any application where a developer needs "pixel perfect" scaling.
Examples include image editors, pixel art, pixel animations, and cases where
developers want to avoid any computational overhead associated with smoothing.



Solution: Codify an existing implementation (see below). My image editor
looked great in Firefox! 

A more complicated solution could allow a developer to specify a specific
smoothing algorithm. Something along the lines of
"context.smoothing('bicubic')."

Existing implementation: "Gecko 1.9.2 introduced the mozImageSmoothingEnabled
property to the canvas element; if this Boolean value is false, images won't
be smoothed when scaled. This property is true by default." Source:
https://developer.mozilla.org/en/Canvas_tutorial/Using_images#Controlling_imag
e_scaling_behavior

Posted from: 65.185.139.106
Comment 1 Scott A 2011-02-12 00:14:13 UTC
Sorry this clobbeed
Comment 2 Tab Atkins Jr. 2011-02-12 00:30:48 UTC
This is handled in CSS through the 'image-rendering' property <http://dev.w3.org/csswg/css3-images/#image-rendering>.  It would be nice to hook into this.
Comment 3 Ian 'Hixie' Hickson 2011-02-16 08:27:18 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: none yet
Rationale: I don't usually like this kind of feature, because it relies on authors making good judgements and that has historically not been a successful strategy for Web browser vendors. However, in this particular case the issue isn't really about optimisation (as it is for 'image-rendering'), it's about a very concrete desire to actually see the pixels blown up. This is something we probably _should_ address.

I've marked this "LATER", so we don't lose track of it. However, now is not a great time to add this, because before adding more new features we should first let the browsers catch up to what we've already specced.
Comment 4 Michael[tm] Smith 2011-08-04 05:03:28 UTC
mass-move component to LC1
Comment 5 Ian 'Hixie' Hickson 2012-02-29 18:53:22 UTC
Just adding context.imageSmoothingEnabled = boolean seems reasonable.
Comment 6 Ian 'Hixie' Hickson 2012-02-29 22:50:14 UTC
Current proposal at: http://wiki.whatwg.org/wiki/Canvas#Image_smoothing
Comment 7 Ian 'Hixie' Hickson 2012-03-28 21:46:15 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: imageSmoothingEnabled for drawImage
Rationale: Concurred with reporter's comments.