[Req]: Improve Windows guest Retina/HiDPI support on macOS ARM

[moreaki]

Problem

On a macOS/Arm host with a Retina display, a Windows 11 Arm guest using VMSVGA with 3D acceleration needs enough 32-bit PCI MMIO space for a 256 MiB framebuffer. A separate fullscreen-transition problem may prevent an already-running guest from receiving the Retina backing-pixel size when it enters macOS fullscreen; that second premise is still under exact A/B validation.

Minimal functional candidates

• Expand ARMv8 MMIO32 for 256 MiB VMSVGA VRAM #743 expands the Armv8 32-bit PCI MMIO aperture from 256 MiB to 448 MiB. The aperture begins at the required 256 MiB-aligned 0xe0000000, leaving room for the 256 MiB VRAM BAR and the remaining platform/device allocations.
• GUI: resend guest resize on macOS fullscreen transition #746 adds one macOS-only call to the existing guest-resize helper when the fullscreen view reaches its maximum size. The existing helper performs the logical-point to Retina-backing-pixel conversion. Direct fullscreen startup is not a valid reproduction because both patched and unpatched builds can reach 5760x3240 that way; the required gate is a windowed-to-fullscreen transition A/B.

The earlier WDDM mode-list proposal (#749) was closed. A source/build audit showed that its local driver path was not compiled or installed in the tested guest, so the observed Windows mode list could not validate that patch. The older screenshot comment below has been corrected in place.

Supporting, independently reproducible fixes

These are not functional HiDPI prerequisites, but were found while making the current VirtualBox tree buildable and the guest graphics path testable:

• Darwin: fix current macOS/Arm build and XPCOM runtime #747: current Darwin/Arm configure/compiler compatibility plus two exact XPCOM runtime fixes. Before the latter fixes, VBoxManage list vms first crashed in nsGenericModule::GetClassObject; after only removing that crash, the result was truncated to "Win" {d486670d-120b-40b6-}. The current tip returns the complete VM name and UUID.
• DXMT: fix the supported LLVM 15 build #748: VirtualBox kBuild integration for the supported vendored DXMT/LLVM 15 combination.
• configure: quote generated shell environment values #752: POSIX-safe quoting in generated env.sh when a PATH entry contains spaces.
• DXMT: keep indexed draw base vertex signed #758 / DXMT: keep indexed draw base vertex signed #754: preserve a negative signed base vertex through vendored DXMT 0.60 (-1 -> 0xffffffff -> 4294967295 before the fix).
• DXMT: forward D3D10 start instance location #761 / DXMT D3D10 DrawIndexedInstanced forwards StartIndexLocation as StartInstanceLocation #760: forward the D3D10 start-instance argument (StartIndex=6, StartInstance=2) instead of passing the start index twice.

The runnable-build documentation request remains tracked in #751, but its former PR was closed because the document depended on unmerged prerequisites and was not independently actionable.

Two additional reports remain intentionally separate:

• macOS/Arm DXMT crash when creating depth/stencil texture with initial data #763 retains the observed depth/stencil crash stack, but the earlier blanket caller-side skip was withdrawn. The report now requires a clean current-main reproduction with the fixed benchmark before a narrower lifetime/state fix is proposed.
• Vendored DXMT 0.60 CPU encoding heap can overflow under large command chunks #765 tracks the vendored DXMT 0.60 CPU encoding-heap overflow. The copied upstream-fix PR was closed because the exact code was authored upstream and the submitted attribution/OCA basis was not valid.

Other integration-hardening proposals from this investigation were closed when their premises or standalone reproductions did not survive review.

Performance candidates

The following draft PRs are optional performance candidates and are not part of the functional series:

• VMSVGA: coalesce DX11 readbacks and skip unchanged updates #744: bounded DX11 dirty readback/coalescing and unchanged-output suppression.
• GUI: draw framebuffer updates without temporary pixmaps #745: direct Qt QImage rectangle drawing without temporary pixmaps.
• GUI: batch framebuffer update notifications #767: coalescing overlapping Qt framebuffer update notifications.

No performance improvement is currently claimed for them. Each is being compared independently using the fixed dxmtbench tool on identical current-main-based builds. A sample is admissible only if its browser framebuffer, guest screenshot, host presentation/signature, launch, and graphics-log gates all pass. A candidate that does not produce a repeatable isolated benefit will be closed.

Current validation status

Base: origin/main commit 5ac81eda707fcf3fcb49f9281401ceac0fc70f4a.

Completed:

• clean Darwin/Arm configure and full build of the surviving non-performance stack;
• strict deep signature verification of the staged app, with VM hypervisor/JIT entitlements retained;
• XPCOM management runtime: complete VBoxManage list vms and showvminfo results;
• patched Expand ARMv8 MMIO32 for 256 MiB VMSVGA VRAM #743 runtime log: pci-mmio32 is 0xe0000000..0xfbffffff (469,762,048 bytes / 448 MiB), with VRamSize=268435456, VMSVGA and 3D enabled;
• patched functional boot: Guest Additions level 3, guest mode 5760x3240, and a screenshotpng framebuffer exactly 5760x3240.

Still required before calling the functional series complete:

• Expand ARMv8 MMIO32 for 256 MiB VMSVGA VRAM #743 negative A/B without the aperture change;
• GUI: resend guest resize on macOS fullscreen transition #746 windowed 3840x2160 -> fullscreen transition A/B. A direct fullscreen boot has already been rejected as non-causal evidence because the unpatched variant also reaches 5760x3240.

Target runtime configuration:

• macOS Arm64 Retina host
• Windows 11 Arm guest
• VMSVGA, 3D acceleration enabled
• 256 MiB VRAM
• Guest Additions run level 3
• 5760x3240 fullscreen functional check
• 3840x2160 fixed-tool correctness/performance checks

[moreaki]

Validation correction (2026-07-16)

This screenshot remains a historical observation that a Windows 11 Arm guest can run at 5760x3240, but it must not be used as merge evidence for #746. The earlier artifact was not reproducibly tied to the current PR tip, and the clean current-main-based A/B showed that an unpatched build can also reach 5760x3240 when it is started directly in fullscreen.

The relevant #746 reproduction is narrower: start the guest windowed at 3840x2160, then enter macOS fullscreen with guest autoresize enabled, and compare the resulting mode with and without the four-line event-filter change. That transition A/B is still pending.

Historical capture details only:

vram=256
accelerate3d="on"
VideoMode="5760,3240,32"@0,0 1
GuestAdditionsRunLevel=3

[moreaki]

Withdrawn as patch evidence (2026-07-16)

This screenshot shows a historical Windows resolution dropdown, but it does not validate the former WDDM mode-list PR #749. A later source/build audit established that the local driver path modified by #749 was not compiled or installed in the tested guest. The observed mode list therefore cannot be attributed to that patch.

PR #749 is closed, and this comment should be treated only as a record of the guest UI state seen at the time.