Now, cairo doesn't support the invert (XOR) drawing. By this, we cannot draw focus outline and caret like as non-cairo build.

Vlad: This is the bug that I talked to you in the office of MJ, please check this and bug 335359.

What is the difference between this bug and bug 359004? Is there one?

Is there a difference between this bug and bug 335394?

This is a bug for gfx/thebes. We need the XOR drawing for outline-color:invert; and caret drawing.

I used to use "invert" for drawing a selection rectangle. Hope to see this fixed soon.

Due to the missing support for invert, a textselection of a word with a background color doesn't look different from other selected text. Only if the background-color is light, the selection is shown in a darker gray.

Text selection doesn't use invert; it switches the selection background and text colors. See bug 56314 and bug 208693.

This is a major regression. Websites and extensions may rely on this, focus rects now draw incorrectly (at least on Windows, where they are inverted) and focused links now look different than in other major browsers (IE for example).

Voting for this bug

On the other hand, link focus rects are always visible when we use the foreground color. With "invert", focus outlines used to be invisible or ugly on mid-dark backgrounds.

Moving to blockign and P2 since this appears to be a regression from 1.8. Pav/Vlad please adjust if you disagree...

(In reply to comment #11) > On the other hand, link focus rects are always visible when we use the > foreground color. With "invert", focus outlines used to be invisible or ugly > on mid-dark backgrounds. We can talk about the style of link hilighting, but buttons and similar widgets should get the right, inverted, focus outline in any case.

What focus rects draw incorrectly? If you mean that they'll look different from the native platform in some cases, then yes, that's true. Buttons and widgets don't look bad at all, so I don't see what the problem is. Supporting this would mean that it would be much harder to do future hardware acceleration; that tradeoff is not worth it. Not supporting this and changing the way we draw cursors and other things that were done with invert before was a decision that was made a while ago; the CJK/font issue in bug 335359 is bad, but I'm sure we can find another solution for that problem.

> With "invert", focus outlines used to be invisible or ugly on mid-dark > backgrounds. This was bug 111526. > Supporting this would mean that it would be much harder to do future > hardware acceleration; that tradeoff is not worth it. I think this was bug 326550. See also bug 287813 and bug 335394. I never really understood why invert / XOR breaks hardware acceleration. Is there a good explanation somewhere?

According to bug 335394 comment #19 this is a regression.

(In reply to comment #15) > I never really understood why invert / XOR breaks hardware acceleration. Is > there a good explanation somewhere? Because computing the final value requires reading the current value first, which is often really expensive -- the hw pipeline tends to be focused on performance in one direction, and to read data back requires stalling the pipeline until the read completes.

Let me point out that 'outline-color:invert' is part of the CSS 2, CSS 2.1 and CSS 3 specs, so it's not just a matter of taste. If you want a conformant user agent, you have to implement inversion. Period. Whether or not inverted outlines should be used for default focus indication is a completely different question. (Neither IE nor Safari/KHTML appear to support the 'invert' value, which is why you hardly ever see it in real-life CSS.)

From http://www.w3.org/TR/CSS21/ui.html#propdef-outline-color The 'outline-color' accepts all colors, as well as the keyword 'invert'. 'Invert' is expected to perform a color inversion on the pixels on the screen. This is a common trick to ensure the focus border is visible, regardless of color background. Conformant UAs may ignore the 'invert' value on platforms that do not support color inversion of the pixels on the screen. If the UA does not support the 'invert' value then the initial value of the 'outline-color' property is the value of the 'color' property, similar to the initial value of the 'border-top-color' property.

CSS3 has similar language in http://www.w3.org/TR/css3-ui/#outline-color0

(In reply to comment #21) > Conformant UAs may ignore the 'invert' value on platforms that do not support > color inversion of the pixels on the screen. Do Windows, Linux and OS X qualify as such platforms?

It's all only software; so sure, you could always write code that could do invert. Now, is it worth taking the tradeoffs that would allow us to support invert, that is losing access to hardware acceleration and other advantages? The answer to that is no. Invert relies on the UA either having access to the framebuffer or keeping around a copy of the previous frame that was rendered. Neither of those is all that great of a thing to be doing. -> WONTFIX

With Mozilla 1.7.13 I get as results: 19406ms with invert 18985ms with black With current trunk build I get as results: 16097ms with invert 14899ms with black This is wile using windowsXP. Mozilla1.7.13 doesn't seem to be slower while using invert drawing.

Martijn, that's because it's not doing hardware acceleration in either case. T.Rosenau@nurfuerspam.de, there is no CSS2.1 or CSS3 "spec" here yet. There is, at best, a CR, which requires interoperable implementations to proceed. CSS2 had no such requirements, which is why parts of CSS2 are in fact not implementable. I could write legislation that requires everyone to never breathe outside their house, but that doesn't make it happen, you know...

Right, CSS2 does not loose a word on inverted outlines. Sorry, my bad. I think there's a bit of confusion on "specification" and "standard" here. I'm well aware of the fact that the specs are merely "Candidate Recommendations" - that's why I wrote "*If* you want a conformant UA..."

W3C produces Recommendations. That's what one conforms to (or not). The drafts you cite are not done yet, and might well change before becomming Recommendations. In fact they change all the time.

Cannot we draw inverted src image to some clipped areas? If we can, we don't need to use framebuffer. And also we don't need to keep around a copy of the previous frame that was rendered.

(In reply to comment #30) > *** Bug 481907 has been marked as a duplicate of this bug. *** If this won't be fixed, it should be mentioned in the documentation: https://developer.mozilla.org/en/CSS/outline-color

This bug just seems to involve recognizing 'invert' as a 'color' in some contexts. works: :focus {outline: thick dotted red;} doesn't work: :focus {outline: thick dotted invert;} works: :focus {outline-color: invert; outline-width: thick; outline-style: dotted;} doesn't work: :focus {outline-color: invert; outline: thick, dotted;} :focus {outline: thick, dotted; outline-color: invert;} :focus {outline: thick, dotted;} In the last case, according to http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines the outline-color property is supposed to default to 'invert'.

(In reply to comment #32) Whoops, some commas snuck into these test cases > doesn't work: > :focus {outline-color: invert; outline: thick, dotted;} > :focus {outline: thick, dotted; outline-color: invert;} > :focus {outline: thick, dotted;} Take out the commas and they all work.

(In reply to comment #31) > If this won't be fixed, it should be mentioned in the documentation: > https://developer.mozilla.org/en/CSS/outline-color done

Is there a chance that you'll change your mind about that bug? This is a really nice feature we miss much.

The stated reason for WONTFIX on this bug is that it's breaking hw acceleration. But the same effect is possible with SVG filters: http://dbaron.org/log/20110430-invert-colors - Can the same method be used to simulate support for "invert" without sacrificing hw acc?

SVG filters apply to an entire group of content, not to one sub-part of the content. So you can do them in hardware by dedicating an entire hardware surface to the thing being filtered and then doing the filter in hardware. That's not really a feasible approach for outlines, unfortunately.

FYI: I have a plan for caret to improve its rendering. At painting caret, currently nsCaret renders itself. http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCaret.cpp#526 My plan is, nsCaret::PaintCaret() calls nsIFrame::PaintCaret(const nsRect aCaretRect). If it failed, nsCaret painted itself. Otherwise, e.g., nsTextFrame fills the rect with currentColor. Finally, it paints its text in the rect with its background color. If we did so, we can support wider caret for Korean IME and back out bug 335359 which cannot fit to native look and feel.

Just got "hit" by this, well nothing too bad but the feature would have been handy ;) Any chance of re-investigating this issue? Could invert rendering ever be done efficiently with the new gfx backend? (which likely changed a lot since Vlad's comment... on modern platforms with FBO this would not require expensive readback afaik)

if i use `ui.caretWidth: 7` and `ui.caretBlinkTime: 0` the letter(s) right next to the cursor position are just blocked by/hidden behind the cursor (osx). smth like `ui.caretInvert: true` would be useful, like in terminal the letter, carret is pointing to, gets inverted, so it stays clear and visible all the time.

Any chance to reimplement it?

http://dev.w3.org/csswg/css-ui/#outline-color "invert" is initial value in the current editor's draft spec. Only IE implemented this. The draft has that derogation: "Conformant UAs may ignore the ‘invert’ value on platforms that do not support color inversion of the pixels on the screen. If the UA does not support the ‘invert’ value then the initial value of the ‘outline-color’ property is the ‘currentColor’ keyword." Should Gecko just be non-conforming (is it?) or should the spec change to absolve Gecko? (Would it make sense to change the initial value from "invert" to "currentcolor", as Presto did? Maybe implementors are less loath than.)

http://dev.w3.org/csswg/css-ui/#outline-color updated regarding invert, in particular note the changes: " Conformant UAs may ignore the invert value on platforms that do not support color inversion of the pixels on the screen. If the UA does not support the invert value then it must reject that value at parse-time, and the initial value of the outline-color property is the currentColor [CSS3COLOR] keyword. " For now I suggest we simply not implement invert, and thus we should drop it at parse-time per the spec.