Issue 434780 in chromium: DirectWrite font rendering does not respect BGR subpixel layout

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Cr-UI Pri-2 Via-Wizard Type-Bug OS-Windows Arch-x86_64

New issue 434780 by debug...@outlook.com: DirectWrite font rendering does
not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/41.0.2224.0 Safari/537.36

Steps to reproduce the problem:
1. Use a BGR monitor or set Cleartype rendering in Windows to use BGR a
layout.
2. Make sure chrome://flags "LCD Text Rendering" is set to default or
enabled.
3. Notice that any font renders in RGB subpixel mode.

What is the expected behavior?
The font respects the monitors / operating systems subpixel rendering mode,
and is not fixed to an RGB layout.

What went wrong?
The font is rendered in RGB subpixel colors rather than BGR, making it look
very bad on BGR monitors.

Did this work before? Yes When the GDI font rendering was default

Chrome version: 41.0.2224.0 Channel: Canary
OS Version: 6.3
Flash Version: Shockwave Flash 15.0 r0

Workaround would be to forcefully disable "LCD Text Rendering", but that
removes the subpixel rendering strategy completely and defaults back to
grayscale / antialias rendering, not looking really good too.



--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Labels: Cr-Blink-Rendering-Subpixel

Comment #1 on issue 434780 by a...@chromium.org: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #2 on issue 434780 by ryan.ai...@gmail.com: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

I have a Dell P2714H and can reproduce this issue.

[chro...@googlecode.com]

Updates:
Cc: e...@chromium.org ana...@chromium.org

Comment #3 on issue 434780 by ebra...@gnu.org: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Owner: fma...@chromium.org
Cc: dan...@chromium.org en...@chromium.org s...@chromium.org
jbr...@chromium.org r...@chromium.org

Comment #5 on issue 434780 by dan...@chromium.org: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

This affects both the Chrome UI and the renderer web content (from
https://crbug.com/434777#c14)

[chro...@googlecode.com]

Updates:
Owner: bunge...@chromium.org
Cc: -r...@chromium.org r...@google.com fma...@chromium.org

Comment #6 on issue 434780 by r...@google.com: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #8 on issue 434780 by r...@google.com: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

cc is now using SkSurface::NewRaster (or NewRenderTarget) to create
surfaces. This is exactly what is needed. I think all that is required is
to correctly communicate the correct SkPixelGeometry to those calls.

enum SkPixelGeometry {
kUnknown_SkPixelGeometry,
kRGB_H_SkPixelGeometry,
kBGR_H_SkPixelGeometry,
kRGB_V_SkPixelGeometry,
kBGR_V_SkPixelGeometry,
};

As ben says, if a requested geometry is not natively supportable (e.g. DW
can't handle it), then skia will automatically downgrade to gray-AA.

[chro...@googlecode.com]

Comment #9 on issue 434780 by e...@chromium.org: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

Sounds reasonable.

What is the right way to access the SkDeviceProperties (and by extension
the SkPixelGeometry value) associated with a SkPaint instance?

[chro...@googlecode.com]

Comment #10 on issue 434780 by r...@google.com: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

I think the need is to access the OS itself, find out the geometry of the
current screen, and convert that to the SkPixelGeometry.h enum (and then
given it to the surface factory).

[chro...@googlecode.com]

Comment #11 on issue 434780 by e...@chromium.org: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

Right, I was specifically asking about the proper way to communicate this
to skia given that we do not seem to explicitly create an SkSurface
instance.

[chro...@googlecode.com]

Comment #12 on issue 434780 by fma...@chromium.org: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

CC is responsible for creating SkSurfaces - I think it needs to figure out
the actual geometry and use that instead of kLegacyFontHost_InitType here:
https://code.google.com/p/chromium/codesearch#chromium/src/cc/resources/resource_provider.cc&l=1126

[chro...@googlecode.com]

Comment #13 on issue 434780 by dan...@chromium.org: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

I think that the browser needs to provide this information to the
renderer's RenderWidget which can put it in the OutputSurface. If the
monitor changes, that maybe means losing the output surface so that cc can
make new resources respecting the new LCD layout.

And for the browser compositor same idea but GpuProcessTransportFactory
instead of RenderWidget.

[chro...@googlecode.com]

Comment #14 on issue 434780 by ryan.ai...@gmail.com: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

You can find the current pixel geometry (called Pixel Structure by
ClearType) in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Avalon.Graphics\<displayName> on the
value named PixelStructure. 0 indicates flat, AKA greyscale; 1 indicates
RGB; and 2 indicates BGR. See here:
http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#pixel_structure

[chro...@googlecode.com]

Comment #15 on issue 434780 by e...@chromium.org: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

Ah, thanks Florin. I don't know much about how this works on the chromium
side. If there is anything we need to do on the blink side or if I can help
with the chrome side changes please let me know!

[chro...@googlecode.com]

Comment #18 on issue 434780 by debug...@outlook.com: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

You mixed up Chrome and Windows in the picture, it's the other way round,
Chrome always does RGB, and Windows does what you set up (BGR in this case).

[chro...@googlecode.com]

Comment #19 on issue 434780 by cka...@gmail.com: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

You are correct, the labels are swapped, my mistake.

Are there any user-side fixes for this issue? It appears to affect both
when is DirectWriting is on and when it is forced off.

[chro...@googlecode.com]

Comment #21 on issue 434780 by cka...@gmail.com: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

It appears I was mistaken on that as well. I had a different, nearby
setting disabled accidentally during testing. This appears to fix the
issue for me. The other option was forcing greyscale anti-aliasing
instead of color, but this appears to be crisper. Thanks.

[chro...@googlecode.com]

Comment #22 on issue 434780 by debug...@outlook.com: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

Yeah but you fall back to slow and ugly GDI font rendering.

[chro...@googlecode.com]

Comment #23 on issue 434780 by cka...@gmail.com: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

Well, I agree that it's not perfect. But until this bug is fixed, I
don't really have a choice. The RGB/BGR bug has been causing me severe
eye strain.

[chro...@googlecode.com]

Comment #24 on issue 434780 by cka...@gmail.com: DirectWrite font rendering

does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

I should add to this actually because the bug is more widespread than I
thought:

Even when you disable colorized sub-pixel rendering, it only affects the
documents displayed, not the GUI of Chrome. Which is then a hodgepodge of
RGB and BGR.

It's actually somewhat hilarious. [See attached]. BGR on tab names, RGB on
address bar, BGR on bookmarks, and grey in the document.

Attachments:
chrome RGB BGR rendering.png 119 KB

[chro...@googlecode.com]

Comment #25 on issue 434780 by debug...@outlook.com: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

Yeah, that's actually discussed in the other bug report by me here:
https://code.google.com/p/chromium/issues/detail?id=434777

[chro...@googlecode.com]

Updates:
Status: Fixed

Comment #27 on issue 434780 by sco...@chromium.org: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

BGR should be fixed by patches in issue# 468509.

[chro...@googlecode.com]

Comment #28 on issue 434780 by rayko...@outlook.com: DirectWrite font

rendering does not respect BGR subpixel layout
https://code.google.com/p/chromium/issues/detail?id=434780

Where is this fixed, or how can I enable BGR subpixel rendering? It's still
forced to RGB for me in Chrome 43.