Lulucat Blog er stedet der vi skriver ned hvordan appene faktisk blir bygget. Her går vi i dybden på renderingsmotorene bak håndskriftverktøyene våre — strekmodeller, viskelær, GPU-pipeliner — måle- og testverktøyene vi bygger for å kunne stole på dem, og ærlige notater om arbeidet med AI-kodeagenter: hva de fikk til, hva de ødela og hva vi beholdt. Ingen fast publiseringsplan; nye innlegg kommer når det faktisk er noe å vise fram.
Krittverktøyet i Lulucat Notes ble tregt i tette håndskriftområder. Flaskehalsen var ikke de 3,571 inndatasamplene, men 70 fullskjerms scratch-pass per bilde. En avvist hurtigbuffer med lav oppløsning og et eget scissorrektangel per strøk forteller resten av historien.
Vi evaluerte Turso/libSQL for håndskriftappen vår på iPad, målte alt og valgte flate snapshot-filer. Arbeidslasten trenger ikke en database — og hvert trinn bør bare betale for problemer som allerede finnes.
Vi ville ha Freeforms retningsbestemte fyllepenn i Lulucat Notes. Spesifikasjonen var et skjermbilde av håndskrift. Etter to modeller, ett spørsmål som skilte mellom dem og en ellipsepennspiss skriver vannpennen slik den skal. Forskningen, koden og valideringen ble gjort av Kimi K3 på Fireworks.
Core Graphics-tile-pipelinen vår ble til en Metal point-sprite-pipeline i seks små trinn, hvert verifisert på en ekte iPad. Koden ble skrevet i parprogrammering med Kimi K3 på Fireworks.
Et viskestrøk som eget element er en opplagt løsning, men objektflytting bryter den. I Lulucat Notes tilhører viskingen derfor strøket som blekket fjernes fra.