fix(gta-core-five): render to temp RTV then CopyResource to shared to eliminate flicker

[IngPleb]

Goal of this PR

Eliminate intermittent checkerboard flickering while using the gamerender texture in NUI WebGL caused by direct writes to the shared backbuffer texture. The use of the texture is required if resource creators what to use css rules like backdrop filters or use WebGL shaders.

Example of such resources:

• fivem-glsl
• tgiann-inventory
• Any resource using the gamerender in CEF

Example of usage in JS/React (remains unchanged after this PR) can be found in the fivem-glsl.

Mentions of this issue:

• https://forum.cfx.re/t/help-random-artifacts-flickering-on-screen/5312324
• Discord servers of resource creators utilizing this method

(If preview of the issues is necessary I shall deliver it upon request)

How is this PR achieving the goal

The rendering path is adjusted so that the backbuffer SRV is first drawn into a private non-shared render target (RTV).
Afterwards, the full frame is GPU-copied (CopyResource) into the shared texture consumed by the overlay/presenter.

This avoids synchronization hazards and guarantees integrity of the shared texture content without visible flickering.

Root-cause hypothesis

• Concurrent use of the shared texture. The old path rendered directly into the DXGI-shared texture that the overlay/presenter samples from. With no keyed mutex or explicit cross-queue fence between producer and consumer, the driver was free to schedule work in an order that exposed partially written frames.

• Driver tiling/fast-clear & partial writes. On some GPUs/drivers, RT writes are tiled and may interact with fast-clears/compression. Under contention, the consumer could read tiles/columns that weren’t written yet (observed as “missing columns” / checkerboard).

• Implicit state transitions aren’t a sync guarantee. D3D11’s implicit RT<->SRV transitions don’t serialize cross-context/cross-proce* access. The shared-handle resource lacked a keyed mutex; the consumer could legally sample while the producer was still drawing.

Performance impact

• Negligible GPU overhead: Adds a single full-frame blit into a private RTV and one CopyResource per frame. From my research these are highly optimized GPU operations and do not involve CPU stalls.

• Minimal VRAM usage: Allocates one extra render target the size of the backbuffer. This is temporary and matches existing texture allocations, so memory footprint increase is negligible on modern GPUs.

• No observable FPS drop: No FPS drop in comparison with the current Canary build of the FiveM client.

Sidenote: This is truly just my hypothesis.

Sidenote 2: Also removed warnings inside the file dating years back.

This PR applies to the following area(s)

• FiveM
• Graphics (DX11 rendering)

Successfully tested on

Game builds: 3258, 1604

Platforms: Windows

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Edit: The PR message was edited by AI to improve its style and fix typos but the code in majority is my human work.