Skip to content

Conversation

@ptziegler
Copy link
Contributor

When the "draw2d.enableAutoscale" system property is enabled, additional (scalable) layers are injected into the IFigure hierarchy to take the monitor zoom into consideration.

As a result of this, translating geometric shapes may cause additional rounding errors, which are the result of translating integer-values with an additional, fractional zoom level.

To work around this problem, the "useDoublePrecision()" method was added with 5cfe5b7, which converts the geometric shapes to their precise variants. This conversion is generally not backwards compatible.

To make sure clients can fully opt-out of this new behavior, this conversion should only be done when the "draw2d.enableAutoscale" is set to true, meaning only when these new layers are added, that require this extended translation logic.

When the "draw2d.enableAutoscale" system property is enabled, additional
(scalable) layers are injected into the IFigure hierarchy to take the
monitor zoom into consideration.

As a result of this, translating geometric shapes may cause additional
rounding errors, which are the result of translating integer-values with
an additional, fractional zoom level.

To work around this problem, the "useDoublePrecision()" method was added
with 5cfe5b7, which converts the
geometric shapes to their precise variants. This conversion is generally
not backwards compatible.

To make sure clients can fully opt-out of this new behavior, this
conversion should only be done when the "draw2d.enableAutoscale" is set
to true, meaning only when these new layers are added, that require this
extended translation logic.
@ptziegler ptziegler force-pushed the hidpi-double-precision-translation branch from 7716e11 to 336726b Compare November 19, 2025 15:09
@ptziegler ptziegler requested a review from azoitl November 19, 2025 15:19
@ptziegler
Copy link
Contributor Author

ptziegler commented Nov 19, 2025

@azoitl As said in #772 (comment), I'm really concerned about the current state of the HiDPI integration in GEF, so far into the release. And would really like to be able to restore the previous behavior with the switch of a flag. wdyt?

@azoitl
Copy link
Contributor

azoitl commented Nov 19, 2025

@ptziegler I have to admit that I lost track about the state. There was so much discussion and I had way to little time. But I have the same impression. If I understand your comment right we could per default turn the flag of for the 3.26 release and reconsider the decision during 3.27. This has the advantage that consumers like @HeikoKlare can already turn it on and other users are free to choose.

I think turning the flag on per default was very important we found many things that otherwise would not be detected. I also think we should try to get some fixes in during the RC phase. Especially if they are no breaking things for users that have the flag turned off.

@ptziegler
Copy link
Contributor Author

I think turning the flag on per default was very important we found many things that otherwise would not be detected. I also think we should try to get some fixes in during the RC phase. Especially if they are no breaking things for users that have the flag turned off.

Now that I've calmed down a little, I think it's fine to keep it enabled for now. My biggest concern was #862, because it effectively blocks me from doing any additional tests. But if this issue is fixed now, I can continue with that tomorrow. I'd say if I don't find anything until the RC2, I'd keep the flag unchanged.

I'll like to keep this PR open until the M1, especially so that I can see whether the tests are still failing with #863.

@ptziegler ptziegler added this to the 3.27.0 milestone Dec 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants