Skip to content

Direct2D: Add ClearType Antialiasing back to D2D as a module option#1610

Open
jthorborg wants to merge 1 commit intojuce-framework:developfrom
jthorborg:d2d/graphics_module_cleartype_option
Open

Direct2D: Add ClearType Antialiasing back to D2D as a module option#1610
jthorborg wants to merge 1 commit intojuce-framework:developfrom
jthorborg:d2d/graphics_module_cleartype_option

Conversation

@jthorborg
Copy link

This is effectively an optional revert of 14d5276.

This adds Windows ClearType font antialiasing back as a disabled-by-default option JUCE_ENABLE_DIRECT2D_CLEARTYPE_FONT_SMOOTHING in the juce_graphics module.

While this can have issues, it seems to fair to have it as a module option for end users to decide.

Disabled example:
billede

Enabled example:
billede

Note the web scaling makes the results look bad, it's purely to demonstrate it works.

This adds Windows ClearType font antialiasing back as a disabled-by-default option "JUCE_ENABLE_DIRECT2D_CLEARTYPE_FONT_SMOOTHING" in the juce_graphics module.
jthorborg added a commit to jthorborg/signalizer that referenced this pull request Jan 3, 2026
@jthorborg jthorborg mentioned this pull request Jan 3, 2026
21 tasks
@jrlanglois
Copy link

Speaking as a JUCE user, I'm not opposed to ClearType support itself, but I do have concerns about the abstraction level chosen here.

Font antialiasing feels like a runtime, aesthetic, and platform-driven concern, rather than something that's best handled as a compile-time, module-wide option. A JUCE_ENABLE_* macro makes the behaviour global and static, which limits an application's ability to follow platform conventions or adapt to different contexts.

The reason for saying this - on Windows, ClearType is a system-level user preference calibrated per display. Overriding that at build time makes it harder for plugins and applications to respect OS and user settings.

While any option risks fragmenting behaviour, my preference would be for JUCE to follow the system/user configuration by default, and only deviate explicitly at runtime (e.g. via LookAndFeel, Desktop, Font, some related place anyway) when an application has a strong reason to do so.

I understand the motivation behind the change; I'm just concerned that a module-level switch places long-lived architectural and UX costs on downstream users.

@jthorborg
Copy link
Author

Speaking as a JUCE user, I'm not opposed to ClearType support itself, but I do have concerns about the abstraction level chosen here. [reasons]

I don't disagree, and I don't mind changing it. I just followed the existing pattern since there's a similar switch for turning coregraphics font smoothing on/off (macos).

It looks like the default-on approach (which used to be the case) isn't ready or there's some sort of issue, take a look at the revert commit description: 9ee072d574a60d615d139df0c5540451b07f0798

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