34 comments

[ 3.4 ms ] story [ 85.9 ms ] thread
(comment deleted)
Correct me if I'm wrong, but I'm pretty sure this has been in Chrome Beta for at least 2 or 3 months - it was hidden in chrome://flags
This is true. I've been using it for a while, but it's great to see it switched on by default. Hopefully more designers will be able to use web fonts without having to worry about how it looks in Chrome/Windows (probably the most popular browser/operating system combination.)
Yep, and I still get errors (letters completely disappearing every few days) with it turned on.
More interestingly for me, the web crypto api has been enabled by default.
It's nice for speed and the fact that you don't need to use a library any more, bit isn't more secure than JS Crypto was before.
> It's nice for speed and the fact that you don't need to use a library any more, bit isn't more secure than JS Crypto was before.

It's a significant improvement in one area: the key storage API. If you use JavaScript crypto, your keys can be read by an attacker who can compromise that code in some way. WebCrypto can't stop that attacker from signing, encrypting or decrypting a message which the attacker has access to but it does prevent the key leaking out, which is often a far more catastrophic event.

This is great. Finally web fonts and icon fonts don't look terrible on Windows/Chrome. I'm using Chrome Canary to test, and you can really see the difference on Google Fonts and the Font Awesome homepage. GDI with ClearType only does anti-aliasing in the x-direction, so the tops of letters like G and Q look pretty blocky in Chrome stable. With DirectWrite they look perfect.
I've been using DirectWrite on Canary as well, and its a huge improvement. Some may even like Chrome's DirectWrite implementation over IE11's, which tends to produce really thick letters for some reason. Here's the same text rendered in IE11, Firefox and Chrome (on Windows 7) -- http://i.imgur.com/pOUJlHE.png
And Firefox rendering here seems kinda green, right?
I can think of two possibilities: 1. IE is honouring the ClearType tuning settings. 2. The default gammas are different.
It looks like IE is using only greyscale anti-aliasing and not sub-pixel anti-aliasing like the others.
Chrome 38 release for Mac on dev channel is now 64-bit.
The support for the dialog element is great, but is it a bug that the scrolling example scrolls the entire page (and moves the dialog offscreen) when the inner scroll bar hits the bottom of the div? Or is that just a limitation of the polyfill?
That's how scrolling inner elements works in all browsers.
It sort of defeats the purpose of a centered modal dialog...
FWIW, This looks terrible for my jenkins logs:

    font-family: monospace;
http://i.imgur.com/da3TbE8.png
That's because the font you're using is set to render without antialiasing – the old system just rendered everything larger and then scaled down (supersampling), while the new system actually uses real antialiasing and only when the flag is set.
I thought they switched the default monospace font to Consolas at the same time?

quote: "The default monospace font on Windows is now Consolas instead of Courier New."

Ah, your screenshot is v36, not v37.

Is it me, or is the text using DirectWrite (in 37) much worse than the text using the manual renderer (in 36)? The harshness of the renderer is one reason I prefer Chrome over IE.
Oh no, it's not you. I say that without DirectWrite font looks nice and smooth. With DirectWrite it's broken, it looks like some Win 3.11 font without anti aliasing. Just look at letter w - you can see pixels forming diagonal lines. And bottom row with grey letters is almost unreadable.

Edit: I was referring to screenshot shown in article, not to DirectWrite in general.

I think you can disable subpixel antialiasing and tweak sharpness for DirectWrite like you could for (Un)ClearType.
I can't find the control panel item for that.
Performance options ("Adjust the appeance and performance of Windows")->Smooth edges of screen fonts

Or is it the "Adjust ClearType text"

DirectWrite isn't using ClearType, so no effect.
If you look at the screenshot at 1:1 resolution http://4.bp.blogspot.com/-4mueYYHRq8I/U8g3U-bk26I/AAAAAAAAAU... you can clearly see that the old renderer is blurry and hard to read, while the new one is crisp and looks much better.
I'm sorry but I still don't share your opinion, even after looking at 1:1 screenshot. Just look at the 'crisp' letter w - for me it's not crisp, it's jagged. I can clearly see vertical line after vertical line (offset to the right), trying to make diagonal lines which constitute the letter. In contrast, "old" style w looks very smooth, much closer to what one would write by hand. Also look at the top of the curve in letter e - it is actually not a curve at all but a horizontal line which stands out.
Pretty sure you have a subpixel order difference or something then - as previously mentioned, screenshots are not the way to compare.
Screenshots can be massively misleading when it comes to font rendering because renderers take display characteristics into account.

Make a screenshot of those and look at it on a different monitor, and things can look very ugly.

The really great thing is that this ends the GDI exhaustion problem. Chrome in Windows could easily kneel systems of users who opened many tabs.
Lately I've found myself using Firefox more and more. The last couple of weeks Chrome and Canary have been hanging a lot, especially when I want to download a file. Chrome will slow to a crawl, tabs will stop rendering and when I try to close it thinks it's still downloading something.

As someone who's been using Chrome since the first public release I wish it were a bit more stable (for me at least).

Check your antivirus.