Barcodes on the phone: how text beat the GPU
Saturday evening. On the phone, the planet labels on my homepage look like barcodes and the golden logo like shattered glass. On the computer everything is fine. That is how one of the most interesting investigations of recent weeks began.
It started with a report every site owner knows: "something looks off on the phone". The labels under the planets in my project system looked like barcodes, the golden emblem in the middle like a stained-glass window after a hailstorm. Desktop: perfect. Phone: chaos. Same site, same code.
Two fixes that fixed nothing
The first lead sounded sensible: textures in unusual sizes can lose quality when scaled down, so I switched the suspicious mechanism off. Deployed, tested - still stripes. The second lead sounded even more sensible: move the graphics to sizes that graphics chips like best. Deployed - still stripes. Two solid, textbook fixes, zero effect.
The breakthrough came from observation, not documentation: the golden logo was breaking too, and it has no text, no shadow, nothing "unusual". Meanwhile the planet spheres, drawn with a different technique, were always clean. The common denominator of the broken elements turned out to be just one - they were all textures uploaded through one specific mechanism, and this phone's graphics driver simply breaks it. You cannot beat a manufacturer's black box. But you can stop playing against it.
The best fix: changing the playing field
I took the text out of the graphics chip entirely. The planet labels are now plain HTML text, positioned every frame with the 3D camera's math - they still orbit, tilt and recede with the planets, exactly as before. The emblem returned to the scene with a different, proven technique, so distant planets hide behind the logo again. No driver on any phone can break HTML text - the problem was not so much fixed as it ceased to exist.
Along the way, two smaller sins surfaced, both typically phone-shaped: the background stars jumped on every scroll (the browser's address bar hides itself and pretends the window changed size, and the code rolled a fresh sky each time) and the page could be nudged slightly sideways. Three deploys later everything stands still, orbits and jumps no more.
What this means for your site
One: a site is a living system, not a poster - it breaks on devices that are not on your desk, so care after launch is not an extra but half the job. Two: when two good fixes do not work, you do not need a third fix, you need a different question. Three: I ran this whole investigation the way I work every day - me and my AI system in the terminal, hypothesis after hypothesis, deploy after deploy, in one evening. That is exactly the approach I teach in the "How I do it" training - the difference being that at yours we build it from zero, on your computer.