On 5/20/20, 4:11 AM, Sergey Bylokhov wrote:
On 5/18/20 10:02 pm, Philip Race wrote:
In what place it assumes that? I mean the test just compares that
Component.getFontMetrics(font) and g.getFontMetrics(font) for the
same component return
the same metrics.
If the component (not-)use AA then shouldn't both methods take care
about that?
I mean that the test assumes that the component and graphics hints
are the same.
Swing is *supposed* to honour the desktop hint for the default L&F
and that is what
we are (now) checking.
If it is assumed that the component and graphics hints should be the
same, isn't it is a bug that they are different?
Right .. it is a bug in the test that it assumes this and that is what I
am fixing.
It is NOT a bug in the product that they are actually different.
Initial bug JDK-8142966 was about differences in metrics when some size
was calculated via Component.getFontMetrics() and then drawn using
metrics
from the graphics. The root cause was about using wrong
GraphicsConfiguration,
isn't the current bug the same? but the root cause is related to the
different
metrics for LCD vs B&W. I guess in this case result could be the same
as in
JDK-8142966, the size will be calculated by one metric, then drawn by
another and the cursor location will be incorrect.
So the test probably should work out of the box.
You aren't understanding and probably haven't read the bug evaluation.
See the latest comment there from Monday, in short, Swing sets the AA hint
on the graphics right before drawing the text and unsets it again right
afterwards.
So for the test to work reliably it needs to do the same thing - although
I don't bother unsetting it since it doesn't matter for the test.
-phil
