It was removed from the specification in 2007.  We should get rid of it, especially as we don't even have a correct implementation.  <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011335.html>
Attachment #450682 - Flags: review?(vladimir)
Comment on attachment 450682 [details] [diff] [review] Patch v1 I'm a little hesitant to remove it, but it should really be gone.. it's not even consistent amongst gecko running on different platforms.
Attachment #450682 - Flags: review?(vladimir) → review+
Uh, I just realized that the test will throw until bug 401788 lands. New patch coming up.
let's just land 401788 first -- I'll take a look at it tomorrow.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b2
Hi! Just wondering, can anybody point me to a discussion as to why the 'darken' operator was removed from the spec? I read about bugs and differing browser implementation, but it's a bit difficult to find detailed informations. I'm currently working excessively with canvas and kind of miss this operator.
Different implementations, and unlikelihood of the implementations converging. If we can't get browsers to implement a feature the same way, we're off better without the feature. You're saying you miss this operator, but which implementation of it do you miss?
Ok, I start to see the problem. I was actually thinking about the "multiply" implementation of Photoshop. But it turns out, that for my usecase a black image with alpha channel works just as well. So, uhm... nevermind!
There is an operation in 3D anaglyphic graphics that requires "darker" -- *requires* it. There is no substitute. I think it was a big mistake to remove it from the feature set. Here's the explanation. If I create an anaglyphic image, a red/cyan image of dots against a black background, it only works if overlapping dots, individually red or cyan, are drawn as white. Easily accomplished -- I use the "lighter" composite operator, Like this: http://i.imgur.com/i4axErQ.png If instead I want a white background, I can draw the exact same image, by using the "darker" composition operator for the overlapping dots. Like this (rendered by Google Chrome): http://i.imgur.com/e5ssBpU.png No problem. But while testing, I discovered that MSIE and Firefox don't support "darker" -- it was dropped without an explanation. The result looks like this in the current Firefox: http://i.imgur.com/lXL8Jek.png You won't fully appreciate the outcome without anaglyphic glasses, but basically it ruins the effect. I tried a few alternatives. the "xor" operator ought to have solved the problem by inverting the entire image after drawing it, but the available "xor" operator doesn't actually work -- it only operates on the alpha channel. I have to say something. I have been creating red/cyan anaglyphic images since I owned an Apple II in 1977. This is the first time I have not been able to produce the images the effect requires. Android supports the "darker" composition operator, so my TankCalc app (https://play.google.com/store/apps/details?id=com.arachnoid.tankcalcandroid), which uses anaglyphs, works fine. But MSIE doesn't support "darker", and Firefox doesn't support it. This is a big step backward. Please reconsider this decision.
It seems that the correct mode in Firefox for the old behavior is globalCompositeOperation="difference". Because "difference" is a mathematical operation, there is no ambiguity in the implementation, unlike the subjective term "darker".
(In reply to Jotaf from comment #11) > It seems that the correct mode in Firefox for the old behavior is > globalCompositeOperation="difference". False. They aren't remotely the same thing. "Difference" equals XOR. "Darker" is something else entirely, that doesn't correspond to a simple logical operator. > Because "difference" is a mathematical operation, there is no ambiguity in > the implementation, unlike the subjective term "darker". Yes, but "difference" equals XOR, and "darker" doesn't -- they aren't the same thing. "Darker" remains unique, and remains necessary. Firefox can close this bug if they want, but Firefox can also be left behind in browser development. One can repair this fault by reprocessing the entire frame, at double or triple the processing time, but this only struggles against an unwise omission.
You need to log in before you can comment on or make changes to this bug.