Local zoom doesn’t initially work in Beta 24 – the session opens zoomed out, at the top-left of the window. Using the Zoom Out and Zoom In buttons makes the session resize properly.
Hi! I’m guessing this is RDP, right? Are you using the MS RDP plugin or the FreeRDP plugin?
We had a couple of related tickets and the root cause is probably a recent PR in the MsRdpEx repo we use. I’ve created an issue on their repo:
opened 11:54AM - 01 Oct 26 UTC
When using the RDP ActiveX control through MsRdpEx, local zoom does not take eff… ect on initial connection if `EnableHardwareMode` is enabled. The remote desktop renders at 1:1 scale in the upper-left corner of the control.
Disabling `EnableHardwareMode` restores local zoom without changing the other connection settings.
### Version comparison
- **2026.6.18:** Local zoom reportedly worked with hardware acceleration configured as enabled.
- **2026.9.21:** The issue occurs.
- **2026.9.25:** Retested; the issue persists.
### ActiveX configuration and initialization
The WinForms host:
1. Sets `EnableHardwareMode` before connecting.
2. Sets `RequestUseNewOutputPresenter = true`.
3. Enables output mirroring through `IMsRdpExInstance.SetOutputMirrorEnabled(true)`.
4. Disables `SmartSizing` when local zoom is enabled.
5. For automatic desktop sizing, requests desktop dimensions divided by the desired zoom factor.
6. Applies the extended `ZoomLevel` property as `VT_UI4` through a queued callback from `OnConnected`.
For example, at 200% zoom, the requested desktop dimensions are half the control dimensions. If zoom is not applied, the session appears at its native size in the upper-left corner instead of filling the control.
### Expected behavior
The configured local zoom factor takes effect after the initial connection when hardware acceleration is enabled.
### Actual behavior
The session renders at 1:1 scale. Disabling hardware acceleration restores the expected scaling.
### Possible connection to #181
PR #181 changed output-mirroring initialization:
- Previously, enabling output mirroring forced `EnableHardwareMode = false`.
- The newer implementation preserves hardware mode and captures DirectX frames.
This could explain why the earlier configuration appeared to work: hardware acceleration may have been silently disabled despite being configured as enabled.
This is a suspected connection, not a confirmed defect in the capture implementation. We have not yet isolated native ActiveX hardware rendering from MsRdpEx capture hooks or established whether applying zoom later resolves the issue.
The host currently ignores the return value of the initial zoom setter, so its success and the subsequent property value still need to be captured.
### Questions
- Is `ZoomLevel` expected to work with `EnableHardwareMode` and `RequestUseNewOutputPresenter` enabled?
- Are there initialization-order requirements for applying local zoom?
- Could output mirroring or the DirectX capture hooks affect zoom application?
As a workaround, disable hardware acceleration.
Right, this is RDP with MS plugin.