search

shjkl / gdipp

Automatically exported from code.google.com/p/gdipp
0 stars 0 forks source link

Font rendering broken in Google Chrome developer build (18) #205

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
Same here too. Bloody unreadable. wtf >_<

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

Attachments:

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
i have the same problems using gdipp v0.7.6 :(

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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
Anyone with a workaround for this?

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
cant find any intances of gdipp

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
hoping this gets fixed soon. my chrome is so ugly :(

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
Isn't MacType based on the old gdi++ code?

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
...Or: disable "GPU Accelerated Drawing" like said before!!

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