perf(web): replace softbuffer canvas present with direct put_image_data

[irvingouj@Devolutions (irvingoujAtDevolution)]

What

Removes the softbuffer dependency from ironrdp-web and presents canvas updates via the 2D context's put_image_data directly.

Why

The old render path did two full-surface pixel passes per frame (RGBA → u32 0RGB, then softbuffer repacks u32 → RGBA into a freshly allocated buffer) plus a per-frame allocation. The new path does a single copy of each dirty region into a reused RGBA scratch (alpha forced opaque) followed by put_image_data at the region origin.

Perf

Record/replay draw bench (dev wasm, headless Chromium), draw-stage median:

• 4K: 1706 ms → 83 ms (~20×)
• 1080p: 705 ms → 14 ms (~50×)

Byte-identical canvas output; unchanged framebuffer checksums. Mirrors the same fix already in IronVNC.

Notes

• softbuffer is only removed from ironrdp-web; ironrdp-viewer (native) still uses it, so it remains in Cargo.lock.
• Adds web-sys CanvasRenderingContext2d + ImageData features.
• Scoped extract of a single commit from the experimental web-rendering work; no other changes.

[irvingouj@Devolutions (irvingoujAtDevolution)]

Same as VNC, remove softbuffer

[Copilot]

Pull request overview

This PR updates the ironrdp-web rendering path to remove the softbuffer dependency and present updated regions by uploading RGBA buffers directly to an HTML canvas via CanvasRenderingContext2d::put_image_data, aiming to reduce per-frame work and allocations.

Changes:

• Replaces the softbuffer-based canvas present path with direct ImageData + put_image_data blits for dirty regions.
• Removes the softbuffer dependency from ironrdp-web.
• Enables additional web-sys features needed for 2D canvas rendering (CanvasRenderingContext2d, ImageData).

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.

File	Description
crates/ironrdp-web/src/canvas.rs	Implements the new 2D-context put_image_data rendering path and removes the softbuffer surface logic.
crates/ironrdp-web/Cargo.toml	Drops softbuffer dependency; enables required web-sys features for 2D canvas + ImageData.
Cargo.lock	Updates lockfile dependency edges to reflect removal of softbuffer from ironrdp-web.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Alex Yusiuk (RRRadicalEdward)]

We can do it faster without filling the buffer with zeros prior to copying, since we are initializing it with data from buffer after all.

if self.rgba.len() < len {
     self.rgba.reserve(len);
     // SAFETY: We later initialize the exact `len` of `self.rgba` by copying `len` bytes from `buffer`. 
     unsafe { self.rgba.set_len(len) };
}

let dst = &mut self.rgba[..len];
dst.copy_from_slice(buffer);

But, I wonder how much of speed up it gives.

Also, we could even make it branchless:

let target_len = max(self.rgba.len(), len);
// In, case `target_len` == `self.rgba.len()`,  `reserve` does nothing, and `self.rgba.set_len` sets a length, which it already contains. 
// In, case ``target_len` == `len`, it's the same case as above. 

self.rgba.reserve(target_len);
// SAFETY: We later initialize the exact `len` of `self.rgba` by copying `len` bytes from `buffer`. 
unsafe { self.rgba.set_len(target_len ) };

let dst = &mut self.rgba[..target_len];
dst.copy_from_slice(buffer);

But, we need to measure both versions. The first one should definitely be faster, than filling with zero.
As for the second version, I'm not sure - we don't have len comparing branch, which is great, but it means that a branch inside self.rgba.reserve(...); executes more often.

[irvingouj@Devolutions (irvingoujAtDevolution)]

Hi Alex, yes I benched it with this branch
There is improvement, but is minimal, around 5-7 ms per draw, which is around 5%, the downside is to introduce unsafe blocks, I personally believe it's not worth it, but let me know

[Alex Yusiuk (RRRadicalEdward)]

5% is nice to have. I don't think that unsafe is that bad, because we work with it correctly

[Benoît Cortier (CBenoit)]

Agree the zero-fill is avoidable. One option to make the intent a bit clearer is spare_capacity_mut(): it hands back a &mut [MaybeUninit<u8>] over the reserved capacity, so we write through MaybeUninit instead of forming a &mut [u8] to not-yet-written bytes (a little friendlier under Miri). It doesn't remove the unsafe though. We still need a set_len afterward to make the bytes live, so it's really a readability/correctness-framing improvement rather than a different category:

if self.rgba.capacity() < len {
    self.rgba.reserve(len - self.rgba.len());
}
let spare = &mut self.rgba.spare_capacity_mut()[..len - self.rgba.len()];
// ... or just keep reserve + set_len; same shape

Honestly the two real choices are still: keep resize(len, 0) (safe, eats the zero-fill) or reserve + unsafe { set_len } (drops it, costs one SAFETY-commented block). For a Vec<u8> scratch the unsafe is legitimate and not UB as long as we only read what we copy.

On significance: the ~5% is a repeatable win, but worth keeping in perspective. The structural change here (killing the double pixel-pass + per-frame alloc) is what got us the 20-50×, and the draw stage isn't the bottleneck anymore at 83ms/4K. So this is mostly a preference call rather than something load-bearing.

That said, I lean slightly toward taking the perf, a single well-scoped unsafe with a clear SAFETY comment is cheap to maintain, and free performance is free performance. Happy either way! 🙂