GNOME Bugzilla – Bug 112479
Antialias GtkHSV widget
Last modified: 2005-04-10 03:24:52 UTC
The focus highlights are barely visible, especially with themes using thin lines with stipple patterns. Additionally the hue wheel and triangle look pretty bad without antialiasing. A patch that fixes these issues is available at http://www.efd.lth.se/~d98gk/gtk/ (along with comparison screenshots).
Created attachment 16321 [details] [review] antialiasing for GtkHSV
Looks pretty good to me (the appearance, haven't looked at the code). Does it respect theme settings like focus-line-width and -pattern ? Should bug 63071 be marked as a duplicate of this ?
focus-line-width and -pattern is ignored. The proper color is used for drawing the highlights though. There are two reasons for this: 1) drawing wider lines either means adjusting the size of the widget to accommodate for the highlights, which means there is an unsightly gap between the circle & triangle when not drawing the triangle highlight, or obscuring the colors the user is trying to pick... 2) line stipples are hard to do antialiased, not to mention slow. wide lines are doable, but require more code to implement. bug 63071, hmm, looks that that what caused this patch in the first place ;-)
Created attachment 16696 [details] [review] Tweak appearance slightly, improve responsiveness a lot
Comments here: - I'm not really happy with the quantity of drawing code being added here for one widget; antialiased drawing is in GTK+'s future (xr.xwin.org), though not until 2.6 or 2.8. I guess it might be worth putting in something temporarily if the appearance is enough better (screenshot? I'm a little lazy here in terms of patching and trying it out) - Is the code that you are adding here for drawing newly written? If you've taken it from somewhere else (even if it's your code), it's probably good to have a note indicating source, author and copyright. (Author and copyright information wouldn't hurt even if it is new code.) - The painting of the focus stuff indicator absolutely needs to obey focus-line-width, and probably the pattern as well. It's OK, however, if the default theme sets these values to something different than it uses for other widgets.
Screenshots: http://www.efd.lth.se/~d98gk/gtk/ The code is written from scratch (by me), there is a reference to the antialiasing algorithm used in one of the comments. License? Same as Gtk. Honouring line width & pattern will have to wait for Xr, Fitz, or whatever ends up replacing the X-centric rendering model in Gtk. I think making the 'Color Name:' field have the default keyboard focus would make it pretty obvious when the ring/triangle is focused, also this is probably the widget somebody using keyboard navigation is most likely to manipulate.
Hmm, the screenshot's are nice, and it's a pretty impressive chunk of code. But I think my comment about not wanting to put in this much code for one widget stands. And as noted in bug 63071, the current ugliness is mostly when *with* a stippled/dashed pattern for the focus indicator. When we turn off the dashing, things look a whole lot better. The accurate comparison is: Aliased, solid vs. Anti-aliased, solid Not Aliased, dashed vs. Anti-aliased, solid And with the accurate comparison, the difference is less, so less of a reason to put in this much code. Thanks for the contribution in any case; we do appreciate it! I'm going to put this on the future milestone for redoing GtkHSV with Cairo (new name of Xr, http://www.cairographics.org) when we do the Cairo/GTK+ integration.
*** Bug 89524 has been marked as a duplicate of this bug. ***
Fixed in HEAD, using Cairo to draw the color wheel