Dar forma, aos poucos, ao que importa.

Pintar o fundo de branco ou salvar a imagem em PNG não cria transparência automaticamente. É preciso um canal alfa separado, que registra quanto de cada pixel deve aparecer.

As imagens estáticas do DINKI passam por segmentação do elemento principal e tratamento de máscaras: o sistema prevê uma máscara de transparência do elemento principal, mantendo as cores originais. Depois, transparência e bordas são verificadas em fundos escuro, verde-lima e papel para preservar detalhes como roupas brancas e reflexos nos olhos.

Os materiais animados seguem outro caminho: a imagem colorida do vídeo e a máscara de transparência são empacotadas juntas; o reprodutor as separa e combina conforme o formato definido. Um componente comum de vídeo pode mostrar blocos de cor ou a máscara. Mudar a cor de fundo não resolve.

O seletor abaixo apenas mostra um material transparente existente sobre fundos diferentes. Ele não envia nem reprocessa suas fotos no navegador.

Para limitar o uso de memória, a solução inicial restringia a quantidade de vídeos reproduzidos ao mesmo tempo. Isso reduzia a carga, mas deixava os demais cartões visíveis parados.

A lista agora usa atlas de quadros transparentes extraídos dos vídeos de movimento: 18 quadros por prévia e orçamento de cache de 32 MiB. Todos os cartões visíveis são reproduzidos; a reprodução pausa durante a rolagem e para fora da tela. Parece um GIF, mas é um atlas de quadros com canal alfa.

Ao abrir um personagem ou reproduzir um movimento completo, os recursos de vídeo continuam sendo usados. A lista não precisa manter um decodificador de vídeo por cartão, e os vídeos originais da produção não são substituídos por prévias de baixa resolução.

A preferência do sistema por movimento reduzido deve continuar sendo respeitada. A fluidez precisa ser medida em dispositivos reais com a mesma carga; não se pode afirmar um ganho de desempenho só com base na implementação.

A conversão cria um momento importante e remove a anotação original. Se os detalhes e a janela de edição estiverem vinculados à mesma anotação, a exclusão deixa a página de baixo sem conteúdo para exibir.

A correção faz o editor manter uma cópia estável do rascunho. Primeiro conclui o salvamento; depois a camada superior recebe o resultado e fecha a conversão e os detalhes pelos retornos de fechamento. As entradas são preservadas ao cancelar ou quando o salvamento falha.

Isso é mais confiável do que emitir duas ordens de fechar a partir de qualquer lugar: cada camada controla sua própria exibição e, após o sucesso, retorna à lista que continua válida.

As confirmações centralizadas reutilizam o componente comum do app, com título, explicação e ação clara, em vez de criar um tipo de aviso em cada página.

O retorno da Apple indica que a transação teve um resultado. O servidor ainda precisa verificar o pedido e seu vínculo e impedir créditos duplicados. Mudar apenas o número na tela deixaria o saldo diferente do registro real.

Nesta rodada, a atualização confirmada da carteira e da assinatura foi reconectada ao cliente, impedindo também que consultas antigas sobrescrevam créditos mais recentes. O andamento aparece no botão de compra; normalmente a pessoa não precisa entender uma ação de “sincronizar compras”.

Pedidos simulados e reais são contabilizados separadamente. Restaurar arquivos também não pode alterar o saldo de compras. Em falhas de rede, as transações pendentes são mantidas e tentadas novamente, sem orientar a pessoa a comprar de novo para receber o crédito.

O plano mensal e as compras de Sol na loja real foram verificados quanto ao crédito, à assinatura e à reabertura. Os fluxos completos de reembolso real e renovação continuam como verificações pendentes antes da publicação.