mirror of
https://github.com/microsoft/PowerToys.git
synced 2025-12-15 19:27:56 +01:00
9f95d9b477
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This fixes two issues with the ZoomIt screenshot save function: - The "actual size" saved bitmap was recomputed from the zoomed-in viewport, leading to artefacts and a non-1:1 pixel accurate output if smooth mode was active. - Two bitmap objects were not deleted after being selected, leading to a leak of 1 or 2 GDI objects per screenshot save operation. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #43323 - [x] Closes: #43352 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments ### GDI object leak In the prior code, bitmap objects were created: ```cpp // Capture the screen before displaying the save dialog hInterimSaveDc = CreateCompatibleDC( hdcScreen ); hInterimSaveBitmap = CreateCompatibleBitmap( hdcScreen, copyWidth, copyHeight ); SelectObject( hInterimSaveDc, hInterimSaveBitmap ); ... hSaveBitmap = CreateCompatibleBitmap( hdcScreen, saveWidth, saveHeight ); SelectObject( hSaveDc, hSaveBitmap ); ``` but were not deleted in the clean-up: ```cpp DeleteDC( hInterimSaveDc ); DeleteDC( hSaveDc ); ``` Deleting their associated device contexts orphans the bitmaps and the GDI objects will not be recovered until ZoomIt is closed. ### Fix The code now uses RAII for handles to DCs and Bitmaps, e.g.: ```cpp wil::unique_hdc hdcZoomed( CreateCompatibleDC(hdcScreen) ); wil::unique_hbitmap hbmZoomed( CreateCompatibleBitmap( hdcScreen, copyWidth, copyHeight ) ); SelectObject( hdcZoomed.get(), hbmZoomed.get() ); ``` The handles are automatically cleaned up when the variables go out of scope. The existing `DeleteDC` code has been removed. ### Screenshot Actual Size save issue ZoomIt's save screenshot routine operated on the currently-displayed view, i.e. the zoomed-in viewport, executing a copy of the full monitor resolution image to begin: ```cpp StretchBlt( hInterimSaveDc, 0, 0, copyWidth, copyHeight, hdcScreen, monInfo.rcMonitor.left + copyX, monInfo.rcMonitor.top + copyY, copyWidth, copyHeight, SRCCOPY|CAPTUREBLT ); ``` (Here hdcScreen represents the zoomed-in image.) When "Actual size" was selected by the user, this bitmap was scaled back down to attempt to reproduce the 1:1 pixel source: ```cpp StretchBlt( hSaveDc, 0, 0, saveWidth, saveHeight, hInterimSaveDc, 0, 0, copyWidth, copyHeight, SRCCOPY | CAPTUREBLT ); SavePng( targetFilePath, hSaveBitmap ); ``` This mostly works if the smooth mode is not applied because the zoom levels tend to produce integer zoomed pixel sizes, although it still produces inexact results at times. The main issue is that the new smooth mode produces a halftone-smoothed output on the display. Attempting to scale this back down to a pixel-accurate source removes high frequency detail and does not reflect the underlying bitmap: Original source: <img width="523" height="186" alt="image" src="https://github.com/user-attachments/assets/7a6dca02-8608-44ed-917f-c6fd1a7b112c" /> "Actual size" save result before fix: <img width="524" height="211" alt="image" src="https://github.com/user-attachments/assets/29c63018-1e8d-4e74-a572-3615686aaa61" /> ### Fix This fix reverses the prior logic. Instead of using the zoomed-in viewport as the screenshot source, we start by blitting a copy of the source bitmap itself, from `hdcScreenCompat`. If a zoomed screenshot is required, this is used as the source of the resize, i.e. we replicate the zoom the user sees in their viewport. This approach: - Is faster and saves memory. It removes the need for an initial `StretchBlt` operation, and the working bitmap itself is significantly smaller if the user is zoomed in. - Saves on the second resize operation if "Actual size" is chosen. We can simply save the copy as-is. - Removes the need to care about monitor coords. All calculations are relative to the top-left of the source bitmap copy. - Simplifies the code. In addition to being able to remove some code, locality is improved - the creation of the zoomed image (and the application of smoothing, if required) is now immediately next to where it is saved. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed (Manual validation on standalone ZoomIt build.) - Confirmed that "Actual size" screenshots are now 1:1 copies of the underlying bitmap, not scaled copies of the screen display. - Confirmed that screenshots no longer leak GDI objects in either "Zoomed" or "Actual size" modes. - Tested cropped and non-cropped saves, i.e. using <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>S</kbd> versus <kbd>Ctrl</kbd>+<kbd>S</kbd>. - Tested that user-added drawing/text was preserved in screenshots. - Tested that both smooth and non-smooth zoom modes operate as they did previously. - Tested on multiple monitors, including a high-DPI external monitor running at 175% scaling. --------- Co-authored-by: Leilei Zhang <leilzh@microsoft.com>