Lulucat Blog é onde registamos como as aplicações são realmente construídas. Espere análises aprofundadas dos motores de renderização por trás das nossas ferramentas de escrita à mão — modelos de traço, borrachas, pipelines de GPU — das ferramentas de medição e verificação que construímos para podermos confiar neles e de notas honestas sobre trabalhar com agentes de programação com IA: o que fizeram bem, o que estragaram e o que decidimos manter. Não há um calendário fixo; surgem novos artigos quando há algo real para mostrar.
A ferramenta de giz do Lulucat Notes ficava lenta em zonas com escrita densa. O estrangulamento não eram as 3,571 amostras de entrada — eram 70 passagens scratch em ecrã inteiro por frame. Uma cache de baixa resolução rejeitada e um retângulo scissor por traço completam a história.
Avaliámos o Turso/libSQL para a nossa aplicação de escrita manual no iPad, medimos tudo e escolhemos ficheiros simples de snapshot. A carga de trabalho não precisa de uma base de dados — e cada passo só deve pagar pelos problemas que já existem.
Queríamos a caneta-tinteiro direcional do Freeform no Lulucat Notes. A especificação era uma captura de ecrã de escrita à mão. Dois modelos, uma pergunta discriminante e uma pena elíptica depois, a caneta de água escreve como deve ser. A investigação, o código e a validação foram feitos pelo Kimi K3 na Fireworks.
O nosso pipeline de mosaicos em Core Graphics tornou-se num pipeline de point sprites em Metal em seis pequenos passos, cada um verificado num iPad real. O código foi escrito em programação aos pares com o Kimi K3 na Fireworks.
Um traço de borracha como elemento próprio parece óbvio. Mover objetos quebra este modelo, por isso, no Lulucat Notes, o apagamento pertence ao traço cuja tinta é removida.
Dados reais do Apple Pencil revelaram falhas que os testes sintéticos não detetaram, levando o Lulucat Notes a trocar três motores de contorno por um modelo de carimbos MaLiang.