The default bug view has changed. See this FAQ.

Cannot use invert for outline and caret drawing

RESOLVED WONTFIX

Status

()

Core
Graphics
--
major
RESOLVED WONTFIX
11 years ago
2 years ago

People

(Reporter: masayuki, Unassigned)

Tracking

(4 keywords)

Trunk
css2, css3, dev-doc-complete, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-IE], URL)

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

10 years ago
Vlad:

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

Comment 2

10 years ago
What is the difference between this bug and bug 359004? Is there one?
(Reporter)

Updated

10 years ago
Duplicate of this bug: 359004

Comment 4

10 years ago
Is there a difference between this bug and bug 335394?
(Reporter)

Comment 5

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

Comment 6

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

Comment 7

10 years ago
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

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

Comment 9

10 years ago
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).
Flags: blocking1.9?

Comment 10

10 years ago
Voting for this bug

Comment 11

10 years ago
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

10 years ago
Moving to blockign and P2 since this appears to be a regression from 1.8.  Pav/Vlad please adjust if you disagree...
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2

Comment 13

10 years ago
(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.
Flags: blocking1.9+ → blocking1.9-
Priority: P2 → --

Comment 15

10 years ago
> 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?

Updated

9 years ago
Depends on: 111526

Updated

9 years ago
Duplicate of this bug: 447876

Updated

8 years ago
Blocks: 468835

Updated

8 years ago
Duplicate of this bug: 418122

Comment 18

8 years ago
According to bug 335394 comment #19 this is a regression.
Keywords: 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.

Comment 20

8 years ago
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.)

Updated

8 years ago
Keywords: css2, css3

Comment 21

8 years ago
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

8 years ago
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
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
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.
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

8 years ago
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.
(Reporter)

Comment 29

8 years ago
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.

Updated

8 years ago
Duplicate of this bug: 481907

Comment 31

8 years ago
(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
Keywords: dev-doc-needed

Comment 32

8 years ago
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

8 years ago
(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

8 years ago
(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

Updated

8 years ago
Keywords: dev-doc-needed

Updated

8 years ago
Keywords: dev-doc-complete
Duplicate of this bug: 650114

Comment 36

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

Comment 37

6 years ago
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.
(Reporter)

Comment 39

6 years ago
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)

Comment 41

4 years ago
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

3 years ago
Any chance to reimplement it?

Comment 43

3 years ago
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.)
Flags: needinfo?(tantek)
Whiteboard: [parity-IE]

Comment 44

2 years ago
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.

Updated

2 years ago
Flags: needinfo?(tantek)
You need to log in before you can comment on or make changes to this bug.