Lulucat Blog to miejsce, w którym zapisujemy, jak naprawdę powstają aplikacje. Czekają tu pogłębione omówienia silników renderujących stojących za naszymi narzędziami do odręcznego pisania — modeli pociągnięć, gumek i potoków GPU — narzędzi pomiarowych i testowych, które budujemy, żeby móc im ufać, oraz szczere notatki z pracy z agentami AI do kodowania: co zrobili dobrze, co zepsuli i co zachowaliśmy. Bez stałego harmonogramu; nowe wpisy pojawiają się, kiedy mamy do pokazania coś konkretnego.
Narzędzie kredy w Lulucat Notes zwalniało w obszarach gęstego pisma odręcznego. Wąskim gardłem nie było 3,571 próbek wejściowych — było nim 70 pełnoekranowych przebiegów scratch na klatkę. Odrzucony cache niskiej rozdzielczości i prostokąt scissor dla każdego pociągnięcia dopełniają tej historii.
Oceniliśmy Turso/libSQL dla naszej aplikacji do odręcznego pisania na iPadzie, wszystko zmierzyliśmy i wybraliśmy płaskie pliki snapshotów. To obciążenie nie wymaga bazy danych — a każdy krok powinien płacić tylko za problemy, które już istnieją.
Chcieliśmy kierunkowego pióra wiecznego z Freeform w Lulucat Notes. Specyfikacją był zrzut ekranu pisma odręcznego. Dwa modele, jedno pytanie rozstrzygające i eliptyczna stalówka później pióro wodne pisze tak, jak powinno. Badania, kod i walidację przeprowadził Kimi K3 na Fireworks.
Nasz kafelkowy potok Core Graphics zmienił się w potok sprite'ów punktowych w Metalu w sześciu małych krokach, z których każdy był sprawdzany na prawdziwym iPadzie. Kod powstawał w parze z Kimi K3 na Fireworks.
Pociągnięcie gumki jako osobny element wydaje się oczywistym rozwiązaniem. Przenoszenie obiektów je łamie, więc w Lulucat Notes wymazywanie należy do pociągnięcia, z którego usuwa tusz.