This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
CanvasPixelArray requires "pixel's red, green, blue, and alpha components being given in that order for each pixel." However in many cases, anyone one or more of these components may be common to all the pixels in the image, for instance the alpha may be common to all pixels, or as at http://www.peepo.com, only red is varied with green = 127, blue = 127 and alpha = 63 for all canvas pixels. if this isn't appropriate please could someone in the WG please clarify why this is best done by setting all four components, for each and every pixel? or perhaps more likely, what aspect I have failed to understand?
Yes, if a particular component is identical for every pixel in your canvas, just fill it in the same for every pixel.
#1 your solution relates to the current practice, but not this enhancement bug: Set component for whole image.
Oh, sorry, I misread your email. You're asking for clarification as to why setting everything is necessary. The answer is simplicity. Most use-cases will be adjusting all four components, so there's not much value to fixing one or more components steady. The one case that's relatively high-value is creating an "opaque" canvas where the alpha is held at 255. Mozilla is currently handling this with a moz-opaque attribute.
no doubt the alpha case for opacity is most likely to be the popular one currently, see CSS. However it is readily apparent there is an excellent use case for data visualisation with each of RGB. peepo.com provides a simple example using canvas, common to many maps, click on the board and observe the change in red saturation, screengrab: http://www.flickr.com/photos/49932622@N05/5623363217/in/photostream/lightbox/ Screens tend to grow with processor speed, and experience (CSS?) suggests that changing a single component at the browser/graphics chip level would considerably reduce temporal artefacts. perhaps a more complex example might be similar to colour separation as used in printmaking. for instance the opacity of each colour layer may more easily be related to the hue. It is possible to manipulate this all on a pixel basis, it certainly appears slower and more complex than the aformentioned CSS method.
please provide a rationale for changing priority
bug 13096 - Enhancement: Set single component for pixel is related.
(In reply to comment #5) > please provide a rationale for changing priority See the bug priority policy as announced by the chairs: http://lists.w3.org/Archives/Public/public-html/2011Jun/0315.html I usually give P5 to feature requests (because they'll often be left alone for a long time) and P4 to minor non-technical issues like typos (because they should be fixed sooner), but there's no real difference and I'm not so consistent. Normally I'll give P2 or P3 to feature requests only if they're particularly important or urgent. The policy outlines what the bug originator should do if they disagree with the bug's assigned priority. I could link to the policy every time I change a bug's priority, but it would be clutter on almost every new bug, and most people don't care. Hope that helps.
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: Did Not Understand Request Change Description: no spec change Rationale: Is there a specific change request here? I don't really understand what the problem is.