On Thu, 24 Mar 2022 03:07:28 GMT, Phil Race <p...@openjdk.org> wrote:
> 2. What I need here is a nice little statement of what we are INTENDING to
> draw. I mean what the UX person sketched out on their paper at infinite
> resolution.
Just my 2c: I'd say the main goal here is to enhance the fidelity of
`EtchedBorder`. Magnify what we see already at 100% scaling nicely so that the
"parts" don't fall apart or overlap inconsistently due to rounding. Note that:
* `TitledBorder` defaults to using `EtchedBorder` in constructors not taking a
`Border`.
* `EtchedBorder` defaults to deriving its 2 colors from the background of the
component it is painting on, when not given explictly
public Color getHighlightColor(Component c) {
return highlight != null? highlight : c.getBackground().brighter();
}
public Color getShadowColor(Component c) {
return shadow != null? shadow : c.getBackground().darker();
}
> Let's assume highlight thickness has to match the border too ? (...) I also
> think there's at least some analogy with OpenJFX's snap-to-pixel idea that it
> is sometimes better to pick a pixel and stick with it rather than span pixels
> and be fuzzy.
These have been my working-assumptions, based on what I see of the built-in L&F
code.
> Can I please have a pretty picture ? Or is there one here already that shows
> this ideal ?
How about an ugly one? ;-) If there is agreement to use sharp, non-aliased
lines of equal thickness at all scaling levels then I believe [the bottom half
of this image
](https://user-images.githubusercontent.com/2722420/159801708-592e9e4d-875b-4b89-aede-306a4f24d78a.png)
shows the desired result, captured @ 250% scaling (2px lines, matching the
width of the CheckBox border). Specifying Red and Yellow explicitly ruins the
'3D' illusion, but makes it easier to spot problems. Title 1 is `LOWERED`
(default). Title 2 is `RAISED`
The trade-off is that the weight of the lines is "quantized" - not smoothly
proportional w.r.t. the scaling. I think it's appropriate for the retro etched
effect, to keep a sharp contrast. An alternative would be to use anti-aliasing
rendering hints (such as is used almost exclusively through the popular
[FlatLaf](https://github.com/JFormDesigner/FlatLaf)).
> If we figure this out properly it might be useful to apply to other cases
> rather than applying inconsistent hacks.
+1
-------------
PR: https://git.openjdk.java.net/jdk/pull/7449
