7 ms·

Performance is nice to be sure, but I think other things are much more important in 2013, like consistent HTML Canvas implementations. For one small example th

Performance is nice to be sure, but I think other things are much more important in 2013, like consistent HTML Canvas implementations. For one small example the in-canvas kerning on both Firefox and Chrome are awful compared to IE10. From a while ago: http://i.imgur.com/62WBzVZ.png http://i.imgur.com/62WBzVZ.png You can see for yourself here: http://jsfiddle.net/vVC4s/ http://jsfiddle.net/vVC4s/ Notice also the difference between doubling the font and doubling the scale, esp where each line gets cut off: http://jsfiddle.net/jGcrL/ http://jsfiddle.net/jGcrL/ This makes animations rickety and un-smooth (text animation): http://jsfiddle.net/simonsarris/HZFcR/ http://jsfiddle.net/simonsarris/HZFcR/ Surprisingly IE10 handles all of these perfectly. Of course, IE10 has totally broken canvas clipping (non-rectangular clipping regions are impossible. They worked fine in IE9.) Firefox does render large text much better than Chrome, which is why I used it when taking screenshots for my book. But scaling the text (as opposed to setting a larger font) is a disaster. This is just an example. I could go on for days about canvas bugs. I wish there was a bigger push to fix those instead of eking out a performance advantage. To Firefox's huge credit, I've submitted a lot of bugs to Chromium and the FF team, and the FF team consistently gets back to me within a week and usually fixes the bug within a month. The bug reporting experience with Chrome on the other hand is rather disenchanting. For a cross-platform bug example, the context's miterLimit is just plain broken by default in Chrome. I reported this (with examples) back in April and have yet to receive any kind of reply. Thank god it's an easy workaround. https://code.google.com/p/chromium/issues/detail?id=225512 https://code.google.com/p/chromium/issues/detail?id=225512 If you want people to use your browser and develop with it in mind, working elements are more important than being slightly faster than the others. (Good developer tools come in close second I think, at least for this crowd).

Aloisius 13y ago
I'm using FireFox 23 on a Mac and the kerning looks just fine on that canvas page for the first example. Aliasing is a little ugly though.
- kunai 13y ago
  That's odd, considering Firefox clones the antialiasing algorithm used by the host OS and uses that to render type. Are you sure that perhaps the OS font rendering settings are to blame, and not necessarily Firefox?
- Derbasti 13y ago
  Same for me. No kerning issues like in the png on OSX.
soundgecko 13y ago
Well, once you get past the tech savvy crowd which is like 1% of the browsing population, even if Firefox truly beats Chrome by a big margin, I don't think this is going to change things one bit for Firefox. Chrome is bundled with Java, Acrobat and Flash updates, which ~98% of computers in the world have. Forget a checkbox in a hurry because you want to do something useful and Chrome is installed. It is bundled with many PCs by the OEMs who get paid for it. It is constantly advertised on TV and on Google properties like Google search engine and Youtube, especially to Opera and IE users. Mozilla doesn't have the resources to do the above and,all this explains Chromes' growth among the nontech crowd more than just performance differences. I have personally seen many folks who I installed Firefox back in the day end up using Chrome. When I ask them, most of the time they don't have no idea how they got it. Google's been sinking a lot of money into Chrome over the years(even paying websites $1 per download they drive) and it makes sense because one more Chrome install they don't have to pay money to Firefox and Opera for being the default search for another user.
siddboots 13y ago
Looks fine on Chromium 25.0/Ubuntu 12.10 and on Firefox 21.0/Ubuntu 12.10
Osmium 13y ago
Just checking in to say that your kerning example looks fine on Safari on OS X (latest stable versions). Which is not to say it's perfect, but there's nothing egregious (no overlaps, no large gaps).
- triptychs 13y ago
  Ditto for Chrome.
jgraham 13y ago
This is not a comment to you in particular, but when authors find bugs in browsers there are several things that they can so to ensure that the bug is fixed as quickly as possible: 1. Verify that the bug occurs in the latest available (possibly unstable/nightly) build. 2. Submit the bug to the relevant browser/engine bug tracking system (see below). If you aren't confident about how to write a good bug report, read [1] first. 3. Write a testcase. If at all possible this should be minimal (i.e. not using the whole of jQuery/Angular/whatever) and should certainly be clear (e.g. no minimised code unless it is actually needed to reproduce the issue). 4. If the bug is a conformance bug rather than a QoI issue, submit your testcase to the W3C [2] so that it can be incorporated into the standard testsuite and automatically run by all browser vendors. To do this the test needs to be written in a standard format [3] and submitted using the process at [4]. At the moment the documentation is a bit sucky, but there is a big revamp in the works [5], so that should improve in the near future. That last one may sound like a lot of effort, but testing is the only way that we will end up with a web platform that is both technologically competitive and open both in spirit and in practice i.e. with multiple interoperable implementations. People put a huge amount of time into working around, and complaining about, cross browser issues. Devoting a small fraction of that time to submitting regression tests instead would dramatically decrease the number of problems in the future. For example submitting a test for canvas clipping both makes it likely that IE will be fixed in the near future, and also ensures that it won't then just regress again one version later. It seems that it would be in the self-interest of big projects like jQuery to commit to creating a test for each time they have to work around some browser bug, so they can expediate fixing the issue, track which browser versions have the bug, and remove the workaround — and thus reduce their code complexity — as soon as the test passes in all the browsers they are targeting. However this is not just something that matters to big projects. If you have run across a bug that is making it difficult to implement something, you are likely the best person in the world to write a testcase for that issue. If you are trying to submit bug reports and tests and need help, please ask on #whatwg on Freenode irc or #testing on irc.w3.org [6]. Bug trackers: Gecko: https://bugzilla.mozilla.org/ WebKit: https://bugs.webkit.org/ Blink: http://crbug.com/ Trident: http://connect.microsoft.com/IE Opera: https://bugs.opera.com/wizard/ [1] http://fantasai.inkedblade.net/style/talks/filing-good-bugs/ http://fantasai.inkedblade.net/style/talks/filing-good-bugs/ [2] https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests [3] https://sites.google.com/site/forthenewbies/home/writing https://sites.google.com/site/forthenewbies/home/writing [4] http://testthewebforward.org/resources/github_test_submission.html http://testthewebforward.org/resources/github_test_submissio... [5] https://github.com/w3c/testtwf-website https://github.com/w3c/testtwf-website [6] http://irc.w3.org/ http://irc.w3.org/
fmoralesc 13y ago
Just to add some data points: In-canvas kerning seems to be affected by the system rendering. In Arch Linux, using Firefox 22 and the Infinality patches, I get http://imgur.com/eRVru67 http://imgur.com/eRVru67 IE kerning is better when scaled up, but it looks just as good or better in regular or scaled down sizes. On the differences between doubling the font and scaling it, I get http://imgur.com/sgu8KYG http://imgur.com/sgu8KYG
mati 13y ago
My experience with reporting bugs in FF/Chrome is a bit different. I reported a bug in canvas text implementation, which occurs in both of those browsers, on Feb 20. I provided all the necessary info and even a minimal test case. The bug has been confirmed in FF quite quickly (within days) and then... nothing. It's quite serious, basically you can't do smooth animation (movement) of text. Similar to the text scaling bug. https://bugzilla.mozilla.org/show_bug.cgi?id=843310 https://bugzilla.mozilla.org/show_bug.cgi?id=843310 Reporting to Chrome has been even worse. No word, no nothing. Not even a confirmation. (Although the submitting process itself has been simpler AFAIR). That's really uncool, after a few of those you lose interest in submitting any more since the feedback feels like "we don't care". So you end up using the time to find workarounds instead. Now obviously someone will point out everyone can go ahead and submit a patch for the bug itself since it's open source. That's all cool and dandy, I love open source as much as the next guy, but please, let's get serious. Who has the time to dive into a massive codebase like that and fix the bug? Not everyone has plans to become a browser developer.
- groby_b 13y ago
  Well, no, you're not seriously expected to submit a patch for a code base like that. If you can, that's awesome, of course :) As for your Chromium bug (http://crbug.com/180300 http://crbug.com/180300) I'd suspect it fell through the cracks with the whole Blink transition. I've tried to narrow down the tags for it, hopefully that will get somebody's attention.
  - davej 13y ago
    This seems to be fixed in Chrome 27. Still broken in Firefox 22 though.
- lxt 13y ago
  I note a Mozilla developer has commented on this bug today: https://bugzilla.mozilla.org/show_bug.cgi?id=843310#c3 https://bugzilla.mozilla.org/show_bug.cgi?id=843310#c3
  - 13y ago
joedrew 13y ago
The kerning differences you're seeing only show up on Windows when not using hardware acceleration (Direct2D). When not using hardware acceleration, Firefox draws text with GDI. GDI doesn't deal well with arbitrary scales applied during text drawing and this explains why the same problems show up in Chrome and Firefox. When Firefox is using DirectWrite/Direct2D (i.e., is using hardware acceleration)—like IE 10—these problems don't show up. Short of heroics, there's not much that can be done to improve text drawing at arbitrary scales with GDI.
homeomorphic 13y ago
> From a while ago: http://i.imgur.com/62WBzVZ.png http://i.imgur.com/62WBzVZ.png Firefox 22 on GNU/Linux looks a lot better, but still not as good as IE: http://imgur.com/GOCmiN9 http://imgur.com/GOCmiN9

Aloisius 13y ago

I'm using FireFox 23 on a Mac and the kerning looks just fine on that canvas page for the first example. Aliasing is a little ugly though.

kunai 13y ago
That's odd, considering Firefox clones the antialiasing algorithm used by the host OS and uses that to render type. Are you sure that perhaps the OS font rendering settings are to blame, and not necessarily Firefox?
Derbasti 13y ago
Same for me. No kerning issues like in the png on OSX.

soundgecko 13y ago

Well, once you get past the tech savvy crowd which is like 1% of the browsing population, even if Firefox truly beats Chrome by a big margin, I don't think this is going to change things one bit for Firefox. Chrome is bundled with Java, Acrobat and Flash updates, which ~98% of computers in the world have. Forget a checkbox in a hurry because you want to do something useful and Chrome is installed. It is bundled with many PCs by the OEMs who get paid for it. It is constantly advertised on TV and on Google properties like Google search engine and Youtube, especially to Opera and IE users. Mozilla doesn't have the resources to do the above and,all this explains Chromes' growth among the nontech crowd more than just performance differences. I have personally seen many folks who I installed Firefox back in the day end up using Chrome. When I ask them, most of the time they don't have no idea how they got it. Google's been sinking a lot of money into Chrome over the years(even paying websites $1 per download they drive) and it makes sense because one more Chrome install they don't have to pay money to Firefox and Opera for being the default search for another user.

siddboots 13y ago

Looks fine on Chromium 25.0/Ubuntu 12.10 and on Firefox 21.0/Ubuntu 12.10

Osmium 13y ago

Just checking in to say that your kerning example looks fine on Safari on OS X (latest stable versions). Which is not to say it's perfect, but there's nothing egregious (no overlaps, no large gaps).

triptychs 13y ago
Ditto for Chrome.

jgraham 13y ago

This is not a comment to you in particular, but when authors find bugs in browsers there are several things that they can so to ensure that the bug is fixed as quickly as possible: 1. Verify that the bug occurs in the latest available (possibly unstable/nightly) build. 2. Submit the bug to the relevant browser/engine bug tracking system (see below). If you aren't confident about how to write a good bug report, read [1] first. 3. Write a testcase. If at all possible this should be minimal (i.e. not using the whole of jQuery/Angular/whatever) and should certainly be clear (e.g. no minimised code unless it is actually needed to reproduce the issue). 4. If the bug is a conformance bug rather than a QoI issue, submit your testcase to the W3C [2] so that it can be incorporated into the standard testsuite and automatically run by all browser vendors. To do this the test needs to be written in a standard format [3] and submitted using the process at [4]. At the moment the documentation is a bit sucky, but there is a big revamp in the works [5], so that should improve in the near future. That last one may sound like a lot of effort, but testing is the only way that we will end up with a web platform that is both technologically competitive and open both in spirit and in practice i.e. with multiple interoperable implementations. People put a huge amount of time into working around, and complaining about, cross browser issues. Devoting a small fraction of that time to submitting regression tests instead would dramatically decrease the number of problems in the future. For example submitting a test for canvas clipping both makes it likely that IE will be fixed in the near future, and also ensures that it won't then just regress again one version later. It seems that it would be in the self-interest of big projects like jQuery to commit to creating a test for each time they have to work around some browser bug, so they can expediate fixing the issue, track which browser versions have the bug, and remove the workaround — and thus reduce their code complexity — as soon as the test passes in all the browsers they are targeting. However this is not just something that matters to big projects. If you have run across a bug that is making it difficult to implement something, you are likely the best person in the world to write a testcase for that issue. If you are trying to submit bug reports and tests and need help, please ask on #whatwg on Freenode irc or #testing on irc.w3.org [6]. Bug trackers: Gecko: https://bugzilla.mozilla.org/ WebKit: https://bugs.webkit.org/ Blink: http://crbug.com/ Trident: http://connect.microsoft.com/IE Opera: https://bugs.opera.com/wizard/ [1] http://fantasai.inkedblade.net/style/talks/filing-good-bugs/ http://fantasai.inkedblade.net/style/talks/filing-good-bugs/ [2] https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests [3] https://sites.google.com/site/forthenewbies/home/writing https://sites.google.com/site/forthenewbies/home/writing [4] http://testthewebforward.org/resources/github_test_submission.html http://testthewebforward.org/resources/github_test_submissio... [5] https://github.com/w3c/testtwf-website https://github.com/w3c/testtwf-website [6] http://irc.w3.org/ http://irc.w3.org/

fmoralesc 13y ago

Just to add some data points: In-canvas kerning seems to be affected by the system rendering. In Arch Linux, using Firefox 22 and the Infinality patches, I get http://imgur.com/eRVru67 http://imgur.com/eRVru67 IE kerning is better when scaled up, but it looks just as good or better in regular or scaled down sizes. On the differences between doubling the font and scaling it, I get http://imgur.com/sgu8KYG http://imgur.com/sgu8KYG

mati 13y ago

My experience with reporting bugs in FF/Chrome is a bit different. I reported a bug in canvas text implementation, which occurs in both of those browsers, on Feb 20. I provided all the necessary info and even a minimal test case. The bug has been confirmed in FF quite quickly (within days) and then... nothing. It's quite serious, basically you can't do smooth animation (movement) of text. Similar to the text scaling bug. https://bugzilla.mozilla.org/show_bug.cgi?id=843310 https://bugzilla.mozilla.org/show_bug.cgi?id=843310 Reporting to Chrome has been even worse. No word, no nothing. Not even a confirmation. (Although the submitting process itself has been simpler AFAIR). That's really uncool, after a few of those you lose interest in submitting any more since the feedback feels like "we don't care". So you end up using the time to find workarounds instead. Now obviously someone will point out everyone can go ahead and submit a patch for the bug itself since it's open source. That's all cool and dandy, I love open source as much as the next guy, but please, let's get serious. Who has the time to dive into a massive codebase like that and fix the bug? Not everyone has plans to become a browser developer.

groby_b 13y ago
Well, no, you're not seriously expected to submit a patch for a code base like that. If you can, that's awesome, of course :) As for your Chromium bug (http://crbug.com/180300 http://crbug.com/180300) I'd suspect it fell through the cracks with the whole Blink transition. I've tried to narrow down the tags for it, hopefully that will get somebody's attention.
- davej 13y ago
  This seems to be fixed in Chrome 27. Still broken in Firefox 22 though.
lxt 13y ago
I note a Mozilla developer has commented on this bug today: https://bugzilla.mozilla.org/show_bug.cgi?id=843310#c3 https://bugzilla.mozilla.org/show_bug.cgi?id=843310#c3
- 13y ago

joedrew 13y ago

The kerning differences you're seeing only show up on Windows when not using hardware acceleration (Direct2D). When not using hardware acceleration, Firefox draws text with GDI. GDI doesn't deal well with arbitrary scales applied during text drawing and this explains why the same problems show up in Chrome and Firefox. When Firefox is using DirectWrite/Direct2D (i.e., is using hardware acceleration)—like IE 10—these problems don't show up. Short of heroics, there's not much that can be done to improve text drawing at arbitrary scales with GDI.

homeomorphic 13y ago

> From a while ago: http://i.imgur.com/62WBzVZ.png http://i.imgur.com/62WBzVZ.png Firefox 22 on GNU/Linux looks a lot better, but still not as good as IE: http://imgur.com/GOCmiN9 http://imgur.com/GOCmiN9