Making room for what matters.

Painting a background white or saving a picture as PNG does not automatically make it transparent. Transparency needs an alpha channel that specifies how much of each pixel should be visible.

DINKI's still images use subject segmentation and mask processing. The model predicts a subject transparency mask while preserving the original colors. The transparent background and subject edges must be checked to protect details such as white clothing and highlights, including checks against dark, lime, and paper-colored backgrounds.

Motion assets use a separate video transparency pipeline: color frames and a transparency mask are packed into a regular video, then split and composited by the player. Playing this asset in a standard video control may reveal color blocks or the mask. Changing the view's background color cannot fix that.

The switch below only shows an existing transparent asset against different backgrounds. It does not upload or reprocess your photos in the browser.

To control memory use, the early approach limited how many videos could play at once. That reduced load but left later visible cards permanently still.

The list now uses transparent frame atlases generated from motion videos: 18 frames per preview and a 32 MiB cache budget. All visible cards animate, pause during scrolling, and stop when offscreen. The result resembles a GIF, but it is a frame atlas with transparency.

Opening a character or playing a full motion still uses the video asset. The list no longer needs a resident video decoder for every card, and the original generated video is not replaced with a low-resolution preview.

The system's Reduce Motion preference still needs to be respected. Smoothness must be measured on real devices under the same workload; an implementation choice alone cannot establish a performance gain.

Conversion creates an important date and removes the original little moment. If both the detail screen and editor sheet depend on that record, deleting it leaves the underlying screen with nothing to show.

The fix gives the editor a stable draft snapshot. Save first, then let the parent handle completion and dismiss the conversion and detail screens through dismissal callbacks. Canceling or failing to save still preserves the input.

This is more reliable than calling dismiss twice from an arbitrary place. Each screen manages its own presentation state, and a successful conversion returns to a view that is still valid.

Centered confirmation dialogs reuse the app's shared component, retaining a title, explanation, and explicit actions instead of building a different prompt on each screen.

An Apple callback means the transaction has a result. The server must still verify the order and its ownership and prevent duplicate crediting. Changing only the displayed number would make the balance disagree with the ledger.

This update reconnects confirmed wallet and membership refreshes to the client and prevents earlier queries from overwriting newer credited results. The interface keeps progress inside the purchase button, so users normally do not need to understand “purchase syncing.”

Simulated and real orders use separate ledgers. Restoring a backup cannot change a purchase balance. During network failures, pending transactions are retained and retried instead of asking users to buy repeatedly just to receive their purchase.

Real App Store monthly membership and Sunlight purchases have been checked for crediting, membership status, and persistence after reopening. Full real refund and renewal flows remain on the pre-release verification list.