I once put a good deal of effort prototyping a full-featured <canvas>-based video player. One feature was subtitles, which was text-on-canvas.
I found that an absolutely positioned div beat the pants off the performance of rendering text to canvas in almost all scenarios. In fact, I would almost never espouse layering of canvas rendering, and rather propose the layering of <canvas> elements themselves and letting markup engines take care of the composition.
There are quite a few "canvas-only" environments now (like Create.js that they built it for)... my favourite in Ejecta http://impactjs.com/ejecta - that let's you wrap up your canvas games/experiments in an iOS app that run really fast (for canvas!)... the guy re-implemented most of the canvas API on top of openGL.
I used to get a good frame rate even on my ancient iPhone 3G. I used simple old-school style bitmap fonts there, though. More retro ;)
Our use case was web2print and mobile support was a big issue. SVG is great but it has mixed mobile support and performance varies. With <canvas> we are able to control rendering fine grained so when the app is not interacted, it is imagelike in performance.
Most of the features in txtjs can easily be ported to SVG as the primary renderer required is SVGPath. FontLoader/Fonts would require zero change but new controls would need to subclass SVG elements. I am very interested in seeing better text in SVG as well as on <canvas> for creative use.
I agree. Txt adds SVGPath support to <canvas> and is how we render glyphs, SVG support would be a great addition to txtjs and many classes would not need to change at all. Rather than render to Canvas, it would subclass SVGElement.
This is pretty great! We've put a lot of work into text for our HTML5 game development, yet our canvas-rendered text is still quite limited in functionality. Using a library like this is going to save us loads of time and really open things up for us.
There were moments in alignment support where I lost a ton of hair and brain cells. The hardest part was getting W3C compliant rendering of SVGPath on <canvas>, after that it was all downhill.
I wrote the beginnings of txtjs on a trip to Bonaire in June. I find I am about 2x-3x as productive writing software during surface intervals while diving than any other time. The diving forces you to relax, think, breath, and you cannot use a computer. When the dive is over, you are 3x productive and things are easier to implement. Also I dive with Nitrox with adds 10% more O2 into the tank, I end up sleeping better, less risk of n2 narcosis, longer bottom times, and I can think very clearly after a dive.
It sounds absurd but I have found I will hit flow more on dive trips than any other time.
I am, although NAUI. Diving leaves me surprisingly sleepy and unmotivated (I don't do any blended air stuff). The idea of cranking out a typesetting engine on a dive boat was a new one. :)
Also this tool shouldn't obfuscate the text content if not explicitly wanted, which in the days of captcha reading OCRs is a desperate measure anyways and doesn't add to the accessibility of the page. Please add the rendered text in the alt attribute of the canvas by default. Or even better make it degrade gracefully to proper HTML by using some CSS replacement technique linking to the dataURL of the dynamically created off-screen canvas image.
Fonts arrive with a units specified, typically 1000 and with values for ascent/decent/xHeight/more.... This provides the basis for font sizing and kerning. In txt we know the relative sizes detailed in the font and we know each character size. This level of detail is unknown to the canvas API today, text is a black box returning images of characters. Also glyphs are drawn inverted along the true baseline so layout is very accurate in dealing with lineHeight and vertical positioning.
If this library can do text-measurements faster than the native canvas measureText() calls can do them, then that part of the library would be interesting to have by itself. That's one thing I know for sure.
20 comments
[ 3.5 ms ] story [ 59.5 ms ] threadI found that an absolutely positioned div beat the pants off the performance of rendering text to canvas in almost all scenarios. In fact, I would almost never espouse layering of canvas rendering, and rather propose the layering of <canvas> elements themselves and letting markup engines take care of the composition.
I used to get a good frame rate even on my ancient iPhone 3G. I used simple old-school style bitmap fonts there, though. More retro ;)
Most of the features in txtjs can easily be ported to SVG as the primary renderer required is SVGPath. FontLoader/Fonts would require zero change but new controls would need to subclass SVG elements. I am very interested in seeing better text in SVG as well as on <canvas> for creative use.
Txt is live in use on:
expressionery.com walmartstationery.com iprint.com
It sounds absurd but I have found I will hit flow more on dive trips than any other time.
Get certified: padi.com
https://code.google.com/p/hyphenator/
https://github.com/bramstein/hypher
Also this tool shouldn't obfuscate the text content if not explicitly wanted, which in the days of captcha reading OCRs is a desperate measure anyways and doesn't add to the accessibility of the page. Please add the rendered text in the alt attribute of the canvas by default. Or even better make it degrade gracefully to proper HTML by using some CSS replacement technique linking to the dataURL of the dynamically created off-screen canvas image.
See HTMLCanvasElement.toDataURL()
Anybody else noticed how slow the canvas measureText() function is on Chrome?