BR: Text in wrong colour if buffered to image

Windows
1

Windows 10, latest tip of develop. Text rendered with Graphics::drawText appears in the wrong colour only if the component is buffered to image. Should be
right
instead of
wrong

Edit: the problem is ClearType rendering on an image context with no background.

2

I don’t know what your experience is, but we’ve find that setBufferedToImage(true) really slows down things on the new Direct2D renderer even though I think it still speeds up the drawing on Mac.

Our solution was to have our own method:

Helpers::bufferToImage(this);

That does nothing on Windows.

3

I’m still buffering to image on D2D in some cases. I have realtime visualizations drawn over seldom changing backgrounds where both are paths with a node per pixel. If I don’t buffer the backgrounds, their constant redrawing slows things down. The paths are not created in paint(), they’re stored, but I don’t know if D2D is caching them, which may make a difference. One optimization I removed was reducing the repaint area to the actually changing part -this made a big difference on the software renderer, but seems to be irrelevant on D2D.

Anyway, after some testing this issue has nothing to do with D2D. ClearType needs to render over the actual background, which is not possible if the component is transparent and rendered to image. So with ClearType enabled, a transparent component with text can’t be buffered.

1 Like
4

In the latest JUCE 8 develop, ClearType is now the default anti-aliasing method when using the Direct2D renderer. Unfortunately, it cannot be disabled without modifying JUCE or globally disabling ClearType at the system level, which affects all applications. I think there should be an option in JUCE to disable ClearType for those who want to opt out of using it.

Here is a similar issue involving ClearType and transparency in the Windows Terminal app: https://github.com/microsoft/terminal/issues/5098

The above issue was resolved by switching to grayscale anti-aliasing on non-opaque backgrounds. The pull request resolving the Windows Terminal issue can be found here:

One potential drawback of resolving the issue by switching to grayscale anti-aliasing in the affected areas is that it may result in ClearType text appearing alongside non-ClearType text in the same app. However, whether or not this discrepancy is an issue is subjective.

5

Thanks for reporting, this issue should be resolved on the develop branch: