Last Comment Bug 359497 - Cannot use invert for outline and caret drawing
: Cannot use invert for outline and caret drawing
Status: RESOLVED WONTFIX
[parity-IE]
: css2, css3, dev-doc-complete, regression
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: -- major with 21 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://dev.w3.org/csswg/css-ui/#outli...
: 359004 418122 447876 481907 650114 (view as bug list)
Depends on: 111526
Blocks: 468835 326550 328340 334635 335359 335394 359496
  Show dependency treegraph
 
Reported: 2006-11-04 02:21 PST by Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
Modified: 2015-07-30 15:05 PDT (History)
31 users (show)
vladimir: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.16 KB, text/html)
2009-02-23 11:29 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details

Description Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2006-11-04 02:21:07 PST
Now, cairo doesn't support the invert (XOR) drawing.
By this, we cannot draw focus outline and caret like as non-cairo build.
Comment 1 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2006-12-24 11:59:43 PST
Vlad:

This is the bug that I talked to you in the office of MJ, please check this and bug 335359.
Comment 2 Gérard Talbot 2007-02-23 15:28:32 PST
What is the difference between this bug and bug 359004? Is there one?
Comment 3 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2007-02-23 15:31:14 PST
*** Bug 359004 has been marked as a duplicate of this bug. ***
Comment 4 Jesse Ruderman 2007-03-17 20:41:17 PDT
Is there a difference between this bug and bug 335394?
Comment 5 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2007-03-18 05:33:06 PDT
This is a bug for gfx/thebes. We need the XOR drawing for outline-color:invert; and caret drawing.
Comment 6 Daniel Kirsch 2007-04-13 05:06:20 PDT
I used to use "invert" for drawing a selection rectangle. Hope to see this fixed soon.
Comment 7 Daniel Kirsch 2007-06-04 02:42:08 PDT
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.
Comment 8 Jesse Ruderman 2007-06-04 10:47:04 PDT
Text selection doesn't use invert; it switches the selection background and text colors.  See bug 56314 and bug 208693.
Comment 9 Jonathan Haas 2007-11-13 16:39:21 PST
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).
Comment 10 Gérard Talbot 2007-11-13 17:05:44 PST
Voting for this bug
Comment 11 Jesse Ruderman 2007-11-13 20:15:23 PST
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.
Comment 12 Mike Schroepfer 2007-11-14 12:05:49 PST
Moving to blockign and P2 since this appears to be a regression from 1.8.  Pav/Vlad please adjust if you disagree...
Comment 13 Jonathan Haas 2007-11-14 13:02:46 PST
(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.

Comment 14 Vladimir Vukicevic [:vlad] [:vladv] 2007-11-14 17:21:46 PST
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.
Comment 15 Jesse Ruderman 2007-11-15 06:24:31 PST
> 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?
Comment 16 Robert Longson 2008-07-24 15:33:26 PDT
*** Bug 447876 has been marked as a duplicate of this bug. ***
Comment 17 Daniel.S 2008-12-14 05:58:56 PST
*** Bug 418122 has been marked as a duplicate of this bug. ***
Comment 18 Daniel.S 2008-12-14 06:01:34 PST
According to bug 335394 comment #19 this is a regression.
Comment 19 Vladimir Vukicevic [:vlad] [:vladv] 2008-12-15 12:41:42 PST
(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.
Comment 20 T.Rosenau 2009-02-21 22:23:16 PST
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.)
Comment 21 Jesse Ruderman 2009-02-22 13:25:52 PST
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.
Comment 22 Jesse Ruderman 2009-02-22 13:27:46 PST
CSS3 has similar language in http://www.w3.org/TR/css3-ui/#outline-color0
Comment 23 Dão Gottwald [:dao] 2009-02-22 13:56:23 PST
(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?
Comment 24 Vladimir Vukicevic [:vlad] [:vladv] 2009-02-22 14:52:37 PST
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
Comment 25 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2009-02-23 11:29:31 PST
Created attachment 363729 [details]
testcase

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.
Comment 26 Boris Zbarsky [:bz] 2009-02-23 14:10:10 PST
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...
Comment 27 T.Rosenau 2009-02-24 00:07:55 PST
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..."
Comment 28 Boris Zbarsky [:bz] 2009-02-24 05:13:06 PST
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.
Comment 29 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2009-02-24 23:01:41 PST
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.
Comment 30 Daniel.S 2009-03-06 11:54:52 PST
*** Bug 481907 has been marked as a duplicate of this bug. ***
Comment 31 Daniel.S 2009-03-06 11:57:26 PST
(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
Comment 32 RodeMcGuire 2009-03-26 13:36:50 PDT
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'.
Comment 33 RodeMcGuire 2009-03-26 13:48:20 PDT
(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.
Comment 34 j.j. 2009-04-13 12:03:40 PDT
(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
Comment 35 Boris Zbarsky [:bz] 2011-04-14 15:15:09 PDT
*** Bug 650114 has been marked as a duplicate of this bug. ***
Comment 36 a4010956 2011-04-15 11:23:23 PDT
Is there a chance that you'll change your mind about that bug?
This is a really nice feature we miss much.
Comment 37 Emil Stenström 2011-05-01 14:19:57 PDT
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?
Comment 38 Boris Zbarsky [:bz] 2011-05-01 16:49:51 PDT
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.
Comment 39 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-05-01 18:37:16 PDT
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.
Comment 40 Cedric Vivier [:cedricv] 2011-05-28 07:54:32 PDT
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)
Comment 41 NN 2013-02-12 11:21:59 PST
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.
Comment 42 decembre56 2014-01-19 01:50:59 PST
Any chance to reimplement it?
Comment 43 j.j. 2014-01-19 07:59:04 PST
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.)
Comment 44 Tantek Çelik 2015-01-09 14:02:33 PST
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.

Note You need to log in before you can comment on or make changes to this bug.