Font rendering broken in Google Chrome developer build (18)

[GoogleCodeExporter]

Which program triggers the problem? Specify the filename if possible.

What steps will reproduce the problem?
1. Open Chrome
2. View any web page

What is the expected output? What do you see instead?
Expect to see fonts render as normal.  When updated to dev build 18, all font 
rendering is broken and unreadable.

What version of gdipp (including renderer)? On which operating system?
0.91 x64 on Windows7 x64

Please provide any additional information below. Screenshots always help.

Original issue reported on code.google.com by shawngma...@gmail.com on 11 Jan 2012 at 9:42

Attachments:

• gdipp_chrome_render.gif

[GoogleCodeExporter]

I can confirm this is happening on my site as well. It used to affect text 
rendered in Chrome with a CSS text-shadow property only. Subsequent Chrome 
updates fixed the issue after the text rendering engine was switched back to an 
older one. Now with development build 18, all text is affected.

Original comment by andrelo...@gmail.com on 11 Jan 2012 at 11:55

[GoogleCodeExporter]

Same here too. Bloody unreadable. wtf >_<

Original comment by lgardent on 20 Jan 2012 at 12:38

Attachments:

• Capture.PNG

[GoogleCodeExporter]

Happening to me too. Looks exactly like the above screenshots, disabling gdipp 
fixes it.

Original comment by resurgen...@gmail.com on 29 Jan 2012 at 5:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've noticed that if you change the fonts used by Google Chrome to something 
else will more than likely fix it. 

The font that was affected for me, was "Arial" - so I changed the font to Segoe 
WP Black (one of the Windows Phone 7 fonts). 

Original comment by MichaelW...@gmail.com on 4 Feb 2012 at 5:48

[GoogleCodeExporter]

Chrome 18 Beta in Windows 7 64 with gdipp. See my screenshots attached. Some 
text becomes entirely unreadable.

Original comment by iisilsp...@gmail.com on 9 Feb 2012 at 10:14

Attachments:

• ScreenShot004.tif

[GoogleCodeExporter]

Chrome 18 has been promoted to the beta channel, so this is afecting many more 
people now. All text is unreadable when gdipp is enabled. Here's a brief 
explanation of what changed on the rendering engine: 
http://blog.chromium.org/2012/02/gpu-accelerating-2d-canvas-and-enabling.html

Original comment by marc...@marceloavalos.com on 10 Feb 2012 at 6:13

[GoogleCodeExporter]

some workaround. it's work for me 

1. load chrome://flags/
2. disable `GPU compositing on all pages`, `Composited render layer borders`, 
`GPU Accelerated Drawing`
3. relaunch Chrome

Original comment by anan...@gmail.com on 18 Feb 2012 at 11:44

[GoogleCodeExporter]

Comment #8 didn't work for me; those options were already disabled so I could 
only "enable" them. I did this for all three of them, restarted Chrome and the 
text still looks blurry. Using Chrome 18.0.1025.33 beta-m, gdipp 0.9.1

Original comment by marc...@marceloavalos.com on 18 Feb 2012 at 3:33

[GoogleCodeExporter]

i have the same problems using gdipp v0.7.6 :(

Original comment by seemannb...@gmail.com on 20 Feb 2012 at 4:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Chrome was rendering HTML5 canvas text nicely until recent Chrome releases. 
Unfortunately, canvas text rendering is terrible (especially compared to FF & 
IE9)now, regardless of GPU & other about:flags settings. 

Original comment by 2ph...@gmail.com on 21 Mar 2012 at 5:22

[GoogleCodeExporter]

Anyone with a workaround for this?

Original comment by psdelar...@gmail.com on 29 Mar 2012 at 8:31

[GoogleCodeExporter]

i added this line <process>chrome\.exe</process> in <exclude> to disabled gdipp.

Original comment by anan...@gmail.com on 30 Mar 2012 at 12:57

[GoogleCodeExporter]

the text is barely ledgible, how do i disable gdipp?

Original comment by sjk.r...@gmail.com on 30 Mar 2012 at 10:02

[GoogleCodeExporter]

Run services.msc, find the 32 and 64 bit instances of gdipp, and click stop for 
each.

Original comment by shawngma...@gmail.com on 30 Mar 2012 at 11:30

[GoogleCodeExporter]

cant find any intances of gdipp 

Original comment by sjk.r...@gmail.com on 30 Mar 2012 at 11:39

[GoogleCodeExporter]

Any workarounds? Really want to use GDIPP. But it fonts in G chrome was broken.

Original comment by karlmosk...@gmail.com on 30 Mar 2012 at 11:41

[GoogleCodeExporter]

My workaround was to downgrade Chrome back to 17 and turn off auto updates 
until a better solution can be found.

Original comment by Ray.S...@gmail.com on 30 Mar 2012 at 3:01

[GoogleCodeExporter]

Been looking for a download link to chrome 17, would you be able to share where 
you got it from?

THanks

Original comment by psdelar...@gmail.com on 30 Mar 2012 at 3:13

[GoogleCodeExporter]

i downgraded as well, you can download it from 
http://www.oldversion.com/Google-Chrome.html or get it from portableapps.com

Original comment by sjk.r...@gmail.com on 30 Mar 2012 at 3:57

[GoogleCodeExporter]

I got my copy of v.17 from FileHippo.com.

Original comment by Ray.S...@gmail.com on 30 Mar 2012 at 8:41

[GoogleCodeExporter]

I think this is happening because Chrome 18 enables hardware acceleration for 
Canvas.

Original comment by corentin...@gmail.com on 31 Mar 2012 at 9:46

[GoogleCodeExporter]

This is really shitty, why has it not been fixed? Turning off auto-updates 
would be awkward

Original comment by iamthef...@gmail.com on 31 Mar 2012 at 7:50

[GoogleCodeExporter]

I'm downgrading to 17 as well which is ridiculous for stable channel.

Original comment by rjsmi...@gmail.com on 2 Apr 2012 at 2:15

[GoogleCodeExporter]

Chromium Issue: http://code.google.com/p/chromium/issues/detail?id=96662

We're taking a look. 

Original comment by vange...@google.com on 2 Apr 2012 at 5:21

[GoogleCodeExporter]

Yes, please fix this. Some sites' text displays fine, but some don't. I don't 
want to downgrade, but I'll probably switch to firefox eventually.

Original comment by Acquie...@gmail.com on 4 Apr 2012 at 3:29

[GoogleCodeExporter]

Copy pasting a comment from Chromium bug tracker (crbug.com/133777) that should 
be relevant in fixing gdipp:

"(From Chrome 18) Skia relies on GetGlyphOutlineW for metrics. The current tip 
of tree gdipp does not hook this call, so Skia cannot reliably know what to 
expect. There is also a development branch of gdipp (which now appears to be 
closed) which does hook GetGlyphOutlineW (this is the branch patched in the 
above linked issue). However, the hook is only reliable on the identity 
transform. In order to achieve certain functionality, Skia almost never uses an 
identity transform with GDI. As a result, even gdipp 0.9.1 does not 
sufficiently implement GDI in order to support Skia."

Original comment by kenjibaheux@chromium.org on 4 Apr 2012 at 8:22

[GoogleCodeExporter]

hoping this gets fixed soon. my chrome is so ugly :(

Original comment by wbut...@gmail.com on 4 Apr 2012 at 8:52

[GoogleCodeExporter]

Latest update from our tracker:

"While GetGlyphOutlineW is an issue as stated above, it does not explain the 
ugliness of what is seen. As it turns out, the way Chrome uses Skia, Skia 
always asks for GDI to draw the text at a size of 64 and uses SetWorldTransform 
to scale to the appropriate size. What GDI does is hint at 64, apply the 
transform to the outline, and then rasterize. Gdipp, on the other hand, is 
rasterizing with freetype at a size of 64 and then using BitBlt from a 
temporary surface into the destination surface. BitBlt is not known for its 
rescaling ability, and this appears to be most of the issue. As an experiment I 
forced all text to 64 pixels and everything looks suprisingly good (though very 
large)"

Original comment by kenjibaheux@chromium.org on 6 Apr 2012 at 6:34

[GoogleCodeExporter]

Maybe this wasn't clear: the issue is on the gdipp side.
MacType had a similar issue which has been fixed as of yesterday.

There is nothing we can do on the Chromium/Chrome side.

Original comment by kenjibaheux@chromium.org on 9 Apr 2012 at 12:42

[GoogleCodeExporter]

I'd definitely recommend people use http://mactype.googlecode.com/ at least 
until the issue is fixed in gdipp.

Original comment by greatq...@gmail.com on 9 Apr 2012 at 1:46

[GoogleCodeExporter]

I've been testing mactype for 2 hours and it does a great job, but that thing 
is very unstable in windows 7 64bit (2 system restarts, open firefox and it 
crashes when service is started).

Also, I couldn't find any documentation/help about mactype. Although, as I 
said, it does a good job on chrome 18+, it seems we should wait until giving 
mactype a chance.

I switched to the "old-heavy-weight" firefox in the meantime. I think I'll be 
back to chrome when Gdipp solves the problem.

Saludos!

Original comment by jesus...@gmail.com on 10 Apr 2012 at 5:05

[GoogleCodeExporter]

Jesus, what version of MacType are you using?  I have been using it for about a 
week now (Win7 x64) and haven't had a single problem.

This is the version I am using: http://code.google.com/p/mactype/

I wish that Windows would just offer this type of font smoothing natively.

Original comment by Ray.S...@gmail.com on 10 Apr 2012 at 12:28

[GoogleCodeExporter]

what config are you using? I installed mactype as a service and in registry and 
both gave me problems.

Original comment by jesus...@gmail.com on 10 Apr 2012 at 10:25

[GoogleCodeExporter]

you may have to start mactype as a tray app, which gives you the maximum 
stability and flexibility.

Original comment by flyingsn...@gmail.com on 11 Apr 2012 at 2:30

[GoogleCodeExporter]

MacType does solve the issue but fonts don't look anywhere near as good as with 
gdipp.

Original comment by cka...@gmail.com on 11 Apr 2012 at 6:00

[GoogleCodeExporter]

Like flyingsn... said, I use MacType as a tray app.  It gives you the 
flexibility of switching rendering modes on the fly.

Cka..., have you tried some of the different profiles in MacType?  The LCD 
profile looks identical to GDIPP.  Also, you can tweak the heck out of any of 
the profiles or create your own.  If you install via the registry or otherwise 
use the default profile, the fonts won't look as nice.  Set up MacType with the 
tray app and use the LCD profile, and I think you'll be happy with it.

Original comment by Ray.S...@gmail.com on 12 Apr 2012 at 11:13

[GoogleCodeExporter]

Hi Kenji, thanks for the comment. As I understand, this issue is similar to the 
Windows GTK problem, i.e., lack of rescaling (issue 24). Correct me if I'm 
wrong. What does Skia need? A compatible and full-fledged GetGlyphOutlineW or 
text output function on a transformed DC?

The tip version is not the source code of 0.9.1. It is not related to this 
issue.

Original comment by crendk...@gmail.com on 13 Apr 2012 at 3:32

[GoogleCodeExporter]

Thanks crendking.

Some additional info from the MacType author on our bug tracker:
"According to the webkit updates, Chrome begin to use internal bitmap bitblt to 
accelerate GDI text rendering, which makes shadow function of gdipp and mactype 
invalid. Moreover, chrome begin to use GDI coordinate transformation to draw 
GDI text, this is what causes gdipp render messed.
The new MacType now support render text on DCs which has transformation 
enabled, thus the chrome can be smoothed"

You might want to check MacType's source code to find out how this exactly 
translate:
http://code.google.com/p/mactype/source/checkout

Let me know if it still is unclear what needs to be done.

Original comment by kenjibaheux@chromium.org on 13 Apr 2012 at 4:44

[GoogleCodeExporter]

Hmm, sorry it seems that there are no source code access to MacType.
I can try to arrange a discussion with the author if needed.

Original comment by kenjibaheux@chromium.org on 13 Apr 2012 at 5:03

[GoogleCodeExporter]

I'd also like to confirm that MacType using the Tray option is a big success. 
I've been using gdipp for so long, but I wish I had found Mactype earlier. It's 
a far superior utility that picked where gdipp left off. It's a substantial 
improvement in quality of the fonts, IMO.

Original comment by iisilsp...@gmail.com on 13 Apr 2012 at 1:53

[GoogleCodeExporter]

I have tried MacType. And it runs very well on both my Win7 x64 and WinXP 
machines.

I tried all the profiles and the LCD is best, but still it doesn't look as good 
as gdipp on my IPS monitors. Text looks too dark. Maybe I'll try tweaking the 
profile.

Original comment by iamg...@gmail.com on 13 Apr 2012 at 5:45

[GoogleCodeExporter]

I agree, none of the default profiles were perfect, so I created this one that 
I think is even better than what I had from gdipp:

http://www.silspd.com/Mactype.zip

Original comment by iisilsp...@gmail.com on 13 Apr 2012 at 8:28

[GoogleCodeExporter]

Indeed, Mactype has sped up the process and actually has a GUI provided to 
choose how you want it to run. Better then a limitation of services. iOS is the 
best font on Mactype imo and comment 44 didn't really go well for me. 

Original comment by djlatino...@gmail.com on 15 Apr 2012 at 10:29

[GoogleCodeExporter]

Isn't MacType based on the old gdi++ code?

Original comment by jmbat...@gmail.com on 15 Apr 2012 at 11:16

[GoogleCodeExporter]

Didn't gdipp just incorporate Easyhook? I mean gdipp and Mactype both started 
out with gdi++

Original comment by djlatino...@gmail.com on 15 Apr 2012 at 11:36

[GoogleCodeExporter]

Installed v17 chrome and worked well. I was playing with Chrome flags 
(chrome://flags/) and I discovered font is rendered incorrectly when "GPU 
Accelerated Drawing" is enabled. Once disabled some sites with big amount of 
images lag a bit, but the font is as it's supposed to be.

Original comment by flaff...@gmail.com on 30 May 2012 at 6:13

[GoogleCodeExporter]

But, in program files/GDIPP, you can open the xml with a notepad an make an 
exclusion ( at the end) for the chrome.exe!!

Original comment by dafma...@gmail.com on 4 Jun 2012 at 3:04

[GoogleCodeExporter]

...Or: disable "GPU Accelerated Drawing" like said before!!

Original comment by dafma...@gmail.com on 4 Jun 2012 at 3:06