[GH-ISSUE #1163] [Bug] Resolution-related features break with Windows zoom not at 100% #3190

New issue

Open

opened 2026-03-01 19:08:12 +03:00 by kerem · 0 comments

kerem commented

2026-03-01 19:08:12 +03:00

Owner

Originally created by @WeatherWonders on GitHub (Dec 6, 2022).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1163

Originally assigned to: @NickeManarin on GitHub.

Describe the bug . . . s
When the Windows display zoom (Control Panel\Appearance and Personalization\Display) is set to 125%, the recorder and editor lose precision. These problems concern recording parts of a screen; I haven't tried to record a full screen.

In the recorder:

The recorder's visual UI, old or new, doesn't accurately reflect the size and position of the recording region, so for precision one has to guess where that region is. More specifically, there are one or two pixels of extra space on either axis. It might be impossible to record certain regions precisely. The magnifier is made much less useful by this bug.
The transparent rectangle outline on the inside of the old recorder UI becomes separated from the solid area at the top when the recording height is set to 125, 128, 130, et cetera.
On occasion, the transparent outline in the old UI, or the dotted outline in the new UI, will overlap the recording region so it is visible in the recording.
Start a recording of height 270 or 540, then stop it so the editor opens. Reopen the recorder from there. The height will be decremented.
Already known, but it seems relevant: the new UI uses recording dimensions a pixel lower on both axes than it says.

In the editor's cropping tool:

It is impossible to crop an image by one pixel in any direction.
Use the tool on a 720x540 image. Set the points to 2, 2, 538, and 718. It will crop a pixel too far on both axes.
If you use the visual controls to expand the cropping area to an entire image of height 241, the "bottom" input will say 240, but it can be incremented by one more.
On an image of height 540, setting "top" to 0 and "bottom" to 537 will cause the preview to say "538", though it will in fact crop to 537.
The preview's reported resolution sometimes changes when you re-enter the number in one of the four inputs (for example by clicking one input and then another). I was unable to reproduce this just now . . .
When scrolling (or using the arrow buttons) on one of the four inputs, it skips numbers ending in 3 or 7. This also happens with the resolution inputs in the recorder.

Desktop

OS: Windows 7
Version 2.37.1
1920x1080 monitors

Originally created by @WeatherWonders on GitHub (Dec 6, 2022). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1163 Originally assigned to: @NickeManarin on GitHub. **Describe the bug . . . s** When the Windows display zoom (Control Panel\Appearance and Personalization\Display) is set to 125%, the recorder and editor lose precision. These problems concern recording _parts_ of a screen; I haven't tried to record a full screen. In the **recorder**: 1. The recorder's visual UI, old or new, doesn't accurately reflect the size and position of the recording region, so for precision one has to guess where that region is. More specifically, there are one or two pixels of extra space on either axis. It might be impossible to record certain regions precisely. The magnifier is made much less useful by this bug. 2. The transparent rectangle outline on the inside of the old recorder UI becomes separated from the solid area at the top when the recording height is set to 125, 128, 130, et cetera. 3. On occasion, the transparent outline in the old UI, or the dotted outline in the new UI, will overlap the recording region so it is visible in the recording. 4. Start a recording of height 270 or 540, then stop it so the editor opens. Reopen the recorder from there. The height will be decremented. 5. [Already known](https://github.com/NickeManarin/ScreenToGif/issues/793#issuecomment-855341011), but it seems relevant: the new UI uses recording dimensions a pixel lower on both axes than it says. In the editor's **cropping tool**: 1. It is impossible to crop an image by one pixel in any direction. 2. Use the tool on a 720x540 image. Set the points to 2, 2, 538, and 718. It will crop a pixel too far on both axes. 3. If you use the visual controls to expand the cropping area to an entire image of height 241, the "bottom" input will say 240, but it can be incremented by one more. 4. On an image of height 540, setting "top" to 0 and "bottom" to 537 will cause the preview to say "538", though it will in fact crop to 537. 5. The preview's reported resolution sometimes changes when you re-enter the number in one of the four inputs (for example by clicking one input and then another). I was unable to reproduce this just now . . . 6. When scrolling (or using the arrow buttons) on one of the four inputs, it skips numbers ending in _3_ or _7_. This also happens with the resolution inputs in the recorder. **Desktop** - OS: Windows 7 - Version 2.37.1 - 1920x1080 monitors

kerem added the

🔷 Bug 🐛

⬜ Pending

labels

2026-03-01 19:08:12 +03:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ScreenToGif#3190

No description provided.

Rows
Columns