Closed
Bug 359497
Opened 18 years ago
Closed 16 years ago
Cannot use invert for outline and caret drawing
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: masayuki, Unassigned)
References
()
Details
(4 keywords, Whiteboard: [parity-IE])
Attachments
(1 file)
(deleted),
text/html
|
Details |
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•18 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•18 years ago
|
||
What is the difference between this bug and bug 359004? Is there one?
Comment 4•18 years ago
|
||
Is there a difference between this bug and bug 335394?
Reporter | ||
Comment 5•18 years ago
|
||
This is a bug for gfx/thebes. We need the XOR drawing for outline-color:invert; and caret drawing.
Comment 6•18 years ago
|
||
I used to use "invert" for drawing a selection rectangle. Hope to see this fixed soon.
Comment 7•18 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•18 years ago
|
||
Text selection doesn't use invert; it switches the selection background and text colors. See bug 56314 and bug 208693.
Comment 9•17 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•17 years ago
|
||
Voting for this bug
Comment 11•17 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•17 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•17 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•17 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?
Comment 18•16 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•16 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•16 years ago
|
Comment 21•16 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•16 years ago
|
||
CSS3 has similar language in http://www.w3.org/TR/css3-ui/#outline-color0
Comment 23•16 years ago
|
||
(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
Closed: 16 years ago
Resolution: --- → WONTFIX
Comment 25•16 years ago
|
||
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•16 years ago
|
||
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•16 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..."
Comment 28•16 years ago
|
||
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•16 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.
Comment 31•16 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•16 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•16 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•16 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
Keywords: dev-doc-needed
Keywords: dev-doc-complete
Comment 36•14 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•14 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?
Comment 38•14 years ago
|
||
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•14 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.
Comment 40•14 years ago
|
||
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•12 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•11 years ago
|
||
Any chance to reimplement it?
Comment 43•11 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.)
Comment 44•10 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•10 years ago
|
Flags: needinfo?(tantek)
You need to log in
before you can comment on or make changes to this bug.
Description
•