finds.dev← search

// the find

gilzoide/unity-texture-apply-async

★ 136 · C · Unlicense · updated Dec 2024

Alternative to Texture2D.Apply() that doesn't require synchronizing with the render thread, avoiding stalls in the main thread

A native Unity plugin that replaces Texture2D.Apply() with an async version that doesn't block the main thread waiting on the render thread. Useful for anyone doing per-frame CPU-side texture writes (procedural textures, video frames, plasma/noise effects) who's hit the Apply() stall in a profiler.

Solves a real, narrow problem correctly — it hooks into Camera.onPreRender for BRP and RenderPipelineManager.beginContextRendering for SRP, so it actually understands the two different Unity rendering paths instead of papering over one. Ships prebuilt native binaries for Windows, Linux, macOS and Android, with source builds documented for iOS/tvOS/visionOS/WebGL via Dockerfiles. The C# API is small and honest about its constraints (schedule once or every frame, cancel, reinitialize, dispose) rather than trying to abstract the danger away.

It's a closed-box native plugin — you're trusting compiled .so/.dll files you can't inspect at a glance, and the C source is a single file with no visible test suite for the native side. The failure modes are sharp and undocumented beyond a README warning: forgetting to call Reinitialize() after resizing a texture 'may crash' your app, and writing to texture data during rendering silently produces garbage frames — there's no guard rail, just a caveat. At 136 stars and one maintainer, this is a niche dependency; if gilzoide stops maintaining it, you're stuck rebuilding native binaries yourself for any new Unity/platform combination.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →