Closed Bug 16380 Opened 20 years ago Closed 12 years ago
Need anti-aliasing for -moz-border-radius style property
This would make this CSS style attribute ready to use for prime time. Can we do it?
As of today I will be working on this border issue.. the issues currently are a resolution problem.. this is causing some funny roundedness at certain scroll posistions.. I do have an anti-alias kind of routine in there, turned off for now until I get the twips to pixel converions popping the borders onto the correct boundries.. thats why some things look good and the same thing looks bad at another position in the page. Things should start shaping up soon.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → REMIND
This is not a for-sure thing, but I will continue to look for solutions.. This is more difficult since it is rendered in twips, so anti-aliasing in smaller than screen space is not a standard approach.
Marking as verified remind
Is this done?
Summary: RFE: Need anti-aliasing for -moz-corner-radius style attrib → RFE: Need anti-aliasing for -moz-border-radius style property
REMIND is deprecated per bug 35839. Is this bug fixed yet?
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
Bulk moving P1-P5 un-milestoned bugs to future.
Target Milestone: --- → Future
*** Bug 214192 has been marked as a duplicate of this bug. ***
Assignee: dcone → other
Status: REOPENED → NEW
QA Contact: chrispetersen → ian
Summary: RFE: Need anti-aliasing for -moz-border-radius style property → RFE: Need anti-aliasing for -moz-border-radius style property (radio buttons are ugly)
*** Bug 222888 has been marked as a duplicate of this bug. ***
Assignee: other → general
Component: Layout → GFX
Summary: RFE: Need anti-aliasing for -moz-border-radius style property (radio buttons are ugly) → Need anti-aliasing for -moz-border-radius style property (radio buttons are ugly)
This bug should really be addressed now that Mozilla Update uses that style. It looks ugly because it's not anti-aliased.
Priority: P3 → --
Summary: Need anti-aliasing for -moz-border-radius style property (radio buttons are ugly) → Need anti-aliasing for -moz-border-radius style property
*** Bug 287075 has been marked as a duplicate of this bug. ***
I'm wondering if this can possibly block Firefox 1.1, maybe 1.2. It's a great dissapointment that it looks so akward at times.
I'm working on some code which I hope to eventually port to C++ to add anti- aliasing for Mozilla (http://verens.com/demos/borders/). However, it looks like Cairo is getting quite a push recently. i wonder is it more worth my while writing my code using the Cairo API than using the usual Mozilla function set? If Cairo becomes ubiquitous, it may solve a lot of antialiasing and other opacity-based problems. Is that the plan?
Cairo is a long ways away from being fully functional. While I do not speak for the Mozilla Cairo code-wrapping developers, I believe that one of the goals of using Cairo is to solve things like the opacity problems for all platforms at once. Personally speaking, I'd love to see better anti-aliasing come to the current gfx implementation. But it's your call, and your time.
There's some antialiasing information for Mozilla2 on the wiki at http://wiki.mozilla.org/Mozilla2:Antialiasing And to help with your decision, some information on the path to Cairo http://wiki.mozilla.org/Mozilla2:GFXEvolution
I think it's best to just continue and get anti-aliasing working correctly in the present gfx set. Cairo does not seem to implement dashed borders at the moment, so whatever solution we come up with will benefit both the present gfx, and also any future work on Cairo in that context. Also, the GFXEvolution page hints that there may not be full coverage for Cairo for some time, especially on lower-end machines such as embedded devices, so fixing the present gfx will be beneficial all-around. Thanks for the thoughts, guys. I hope to have some example anti-aliasing code for rounded borders (as well as bevelled corners) completed by the end of the week.
Did I say "end of the week"? As my own boss knows, I'm a little **** at indicating the length of a job. I think I've finished with the basic anti-aliasing work: http://kae.verens.com/demos/borders/anti-aliased.html I will not be re-writing that in C++ yet, though - I am not finished with dashes, doubled borders, etc. Once those are done, it will be ready for inclusion (and in dire need of optimisation!). Note that the example is ellipsoid - it conforms to the W3C draft, as far as I know.
http://webkit.opendarwin.org/blog/?p=22 Safari does it. Whats the status of the Gecko implementation? Is there a chance it makes into 1.9?
I'm waiting for Cairo to be integrated fully into the engine before I goany further with my own attempts. Cairo has anti-aliasing built-in, and curves, so it should make this simple to implement once it's in.
Seems fixed in latest trunk (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060302 Firefox/1.6a1).
Since we're using Cairo now this is fixed.
Status: NEW → RESOLVED
Closed: 20 years ago → 14 years ago
Resolution: --- → WORKSFORME
*** Bug 343252 has been marked as a duplicate of this bug. ***
Does anyone know the number of the bug for the artefact visible in the cairo example of the trunk vs 1.8 comparison?
That would be bug 328241
This doesn't seem to be fixed for Linux.
Status: RESOLVED → REOPENED
OS: All → Linux
Resolution: WORKSFORME → ---
Target Milestone: Future → ---
I can't find the bug at the moment, but there's a bug for turning on antialiasing under linux -- it was turned off due to serious performance issues.
Flags: blocking1.9? → blocking1.9-
(In reply to comment #28) > I can't find the bug at the moment, but there's a bug for turning on > antialiasing under linux Bug 381735. Ironically, that one is blocking1.9.
Depends on: 381735
Status: REOPENED → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.