I use an older iPad and the page crashed so hard the Home button didn’t do anything for about 30 seconds. The iPad eventually turned off, because I had pressed the power button, to no avail, a couple of times.
Thank you! To be fair, there's plenty of room for optimisation. I have only tested on an M1 on Chrome. It's a tradeoff between looking cool and being performant
True — good optimization can get you both. It used to be way less performance, I already tried to optimise (at least until my machine was running it fine), but it seems like there's still much more that can be done
If you can’t figure it out based on the git blame and git diff, the code is incredibly unreadable. A comment in the code, or simply writing better readable code seems like a better investment.
Besides, a few passes refactoring and your git history is ruined. No way you’ll find the original commit within any reasonable time frame.
If I move the code to another function, your original commit message will be hard to trace. If the code was commented, the comment would have been moved along. If the code was readable, you don’t need the comment or the commit message.
I can only speak from my own experiences, but I have found commit messages extremely helpful, when they explain the "why" of the change. And as unfortunate as it is, many of us also have to work with unreadable codebases.
No, they say they are not going to store a bitmap in a texture, which is not the same thing as embedding directly in the shader code.
You could compare that to storing some data in a separate file which needs to be read during runtime versus embedding the data directly in the source code.
The bitmap absolutely is a texture in the broad sense of the word. It’s not a Vulkan texture in the sense that it doesn’t use the Vulkan texture API, but it is a texture nonetheless.
Moreover, parent’s point is double valid because of the example “Look Ma, No Font Atlas!!!” that uses a font atlas baked into shader code. I totally expected this article, based on the title, to talk about stroked font rendering, and instead it’s an article about “texture-less” textured rendering that uses a “no font atlas” font atlas.
The effect of that is that you're circumventing using hardware specialized for efficient pixel lookup in favor of using general data lookup inside the shader binary. You're saving yourself some memory due to using 1 bit per pixel rather than at least 8 (none of the major APIs expose a 1-bit texture format AFAIK so R8 would be the next best thing), but you're bound to use some extra cycles for the lookup and decoding of your embedded font.
> none of the major APIs expose a 1-bit texture format AFAIK so R8 would be the next best thing
I think the next best thing is BC4. The compressed format stores 8 bits/pixels grayscale texture compressed into 8 bytes / 4x4 pixels i.e. 4 bits/pixel, twice smaller compared to R8.
While not technically misleading, I also find it a bit misleading.
When told it's going to be a "texture less text rendering", I was thinking of procedural drawing of glyphs, not embedding bitmaps in a shader instead of a texture.
> Obviously, we can’t store bitmaps inside our shaders, but we can store integer constants, which, if you squint hard enough, are nothing but maps of bits. Can we pretend that an integer is a bitmap?
He seems a bit confused about what a bitmap is. There's no squinting or pretending involved here.
Memory is memory, irrespective of whether it's "code memory" or "data memory".
Back in the bad old days you could just use precompiled textures which are basically a set of memory write CPU instructions using immediate mode operands (no texture/bitmap lookup of any kind)
