# Local Zoom slightly broken in beta 24

**URL:** https://community.royalapps.com/t/local-zoom-slightly-broken-in-beta-24/2395
**Category:** Royal TS (for Windows)
**Created:** [September 30, 2026, 7:13pm UTC](https://community.royalapps.com/t/local-zoom-slightly-broken-in-beta-24/2395 "2026-09-30T19:13:44Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![jernej\_simoncic](https://community.royalapps.com/user_avatar/community.royalapps.com/jernej_simoncic/32/1763_2.png) [@jernej\_simoncic](https://community.royalapps.com/u/jernej_simoncic)
#### Post date: [September 30, 2026, 7:13pm UTC](https://community.royalapps.com/t/local-zoom-slightly-broken-in-beta-24/2395/1 "2026-09-30T19:13:44Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![stefan\_koell](https://community.royalapps.com/user_avatar/community.royalapps.com/stefan_koell/32/9_2.png) [@stefan\_koell](https://community.royalapps.com/u/stefan_koell)
#### Post date: [October 1, 2026, 10:04am UTC](https://community.royalapps.com/t/local-zoom-slightly-broken-in-beta-24/2395/2 "2026-10-01T10:04:39Z")

</div>

Hi! I’m guessing this is RDP, right? Are you using the MS RDP plugin or the FreeRDP plugin?

---

<div class="post-metadata">

### Author: ![stefan\_koell](https://community.royalapps.com/user_avatar/community.royalapps.com/stefan_koell/32/9_2.png) [@stefan\_koell](https://community.royalapps.com/u/stefan_koell)
#### Post date: [October 1, 2026, 11:57am UTC](https://community.royalapps.com/t/local-zoom-slightly-broken-in-beta-24/2395/3 "2026-10-01T11:57:00Z")

</div>

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:

> <https://github.com/Devolutions/MsRdpEx/issues/195>
>
> 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.

---

<div class="post-metadata">

### Author: ![jernej\_simoncic](https://community.royalapps.com/user_avatar/community.royalapps.com/jernej_simoncic/32/1763_2.png) [@jernej\_simoncic](https://community.royalapps.com/u/jernej_simoncic)
#### Post date: [October 1, 2026, 1:54pm UTC](https://community.royalapps.com/t/local-zoom-slightly-broken-in-beta-24/2395/4 "2026-10-01T13:54:23Z")

</div>

Right, this is RDP with MS plugin.
