Uploaded January 2019 | Updated September 2026, 3 weeks ago
I wanted to show a small, isolated case where careful design of errors can lead to a much better experience for you users.
In the case of our GraphiQL instance, normalizing the “missing-auth” error across lots of different services means we can have very little error-handling code, but still direct the user in a step-by-step way.
I wanted to show a small, isolated case where careful design of errors can lead to a much better experience for you users.
In the case of our GraphiQL instance, normalizing the “missing-auth” error across lots of different services means we can have very little error-handling code, but still direct the user in a step-by-step way.
![Glint: Text rendering with align & word-wrap [no narration] (2014)](https://i.ytimg.com/vi/G-ej_ZrAb_8/mqdefault.jpg "Glint: Text rendering with align & word-wrap [no narration] (2014)
September 3, 2014
Added text rendering with a few extras - and this represents a ton of work. The original route we were looking into involved generating geometry from font files, and using fragment shaders to fill in the actual pixels. Getting resolution-independent rendering of fonts this way is lovely. However, that’s a pretty painful route, and also means that we would have had our own font rendering engine, and while not always a bad thing, the challenge of supporting it and of getting it to render anywhere near the browsers would have been a nightmare. It’s still something interesting long-term, but we needed a much shorter route for this iteration.
We ended up using what’s now more-or-less the standard for WebGL: Render text to a 2d-canvas, and then copy that as a bitmap image over to the GPU to use as a texture on some geometry. This has the advantages of being easier to implement while still being reasonably fast (we only pay the render and transfer cost on creation and update to the text), and more importantly, it uses the native font-rendering engines that the browsers use. This means our users will see what it’s going to look like in the final product with much greater fidelity. The disadvantage of this approach is that it’s not resolution-independent, so making it look good at all zoom levels is still a lot of work.
Either way we go, doing things like word-wrap and text alignment are completely up to us, so I had a fun afternoon implementing those properly. And I haven’t yet implemented underline or drop shadows, but the PIXI library has a pretty good solution for this that I may base my solution off of. In the meantime, there’s actually a bug with right-aligned text that I discuss in the video for those of you interested!")
