[GH-ISSUE #915] [Question] Why recording in full-screen mode adds a border with random color?

kerem commented

2026-02-26 09:32:22 +03:00

Owner

Originally created by @wenfangdu on GitHub (Jun 13, 2021).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/915

Version: v2.31

I recorded 5 GIFs here, all of them have borders with different colors, how to turn the borders off when recording new GIFs in full-screen mode?

Also, how to trim the borders off on the already recorded GIFs?

P.S.

I didn't use the border function, these borders are added automatically when recording in full-screen mode.
My screen's resolution is 1920*1080, but the recorded GIFs are 1922*1081 / 1922*1082.

Originally created by @wenfangdu on GitHub (Jun 13, 2021). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/915 Version: `v2.31` I recorded 5 GIFs [here](https://github.com/wenfangdu/vscode-jump#demos), all of them have borders with different colors, how to turn the borders off when recording new GIFs in full-screen mode? Also, how to trim the borders off on the already recorded GIFs? P.S. - I didn't use the `border` function, these borders are added automatically when recording in full-screen mode. - My screen's resolution is 1920\*1080, but the recorded GIFs are 1922\*1081 / 1922\*1082. ![image](https://user-images.githubusercontent.com/28700378/121810931-2ea9b780-cc95-11eb-8dc2-811527be1f05.png)

kerem added the

🔷 Bug 🐛

⬜ Pending

🕙 Low

labels

2026-02-26 09:32:22 +03:00

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@pawlos commented on GitHub (Jun 14, 2021):

@wenfangdu No automated tasks that adds a border to the recording? You can check that in Options->Tasks.

As for removing the border, if it's already on the frames the only (I think) option would be to use the crop and the rid of it.

@pawlos commented on GitHub (Jun 14, 2021): @wenfangdu No automated tasks that adds a border to the recording? You can check that in Options->Tasks. As for removing the border, if it's already on the frames the only (I think) option would be to use the crop and the rid of it.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@NickeManarin commented on GitHub (Jun 14, 2021):

@pawlos @wenfangdu

Yes, that looks like a border (with negative values that ends expanding the frames) being inserted by an automated task.
It could also be related to issues with high screen DPI and the recorder not correctly detecting the size of the capture region.

@NickeManarin commented on GitHub (Jun 14, 2021): @pawlos @wenfangdu Yes, that looks like a border (with negative values that ends expanding the frames) being inserted by an automated task. It could also be related to issues with high screen DPI and the recorder not correctly detecting the size of the capture region.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@wenfangdu commented on GitHub (Jun 14, 2021):

@pawlos @NickeManarin

No automated tasks for that (only has a default mouse-clicking task):

I tried cropping the recorded GIFs, works well so far.

It could also be related to issues with high screen DPI and the recorder not correctly detecting the size of the capture region.

My current screen is 22.5 inches, 1920*1200, the zoom level is 100%, so I guess that's not high screen DPI? The recorded GIF size is 1922*1201 / 1922*1202, which exceeds my screen's size, the recorder didn't correctly detect the capture region size. How to let it detect correctly when recording new GIFs in full-screen mode?

Another setting that might be relevant: I use "Automatically Hide The Taskbar In Desktop Mode" for the windows 10 taskbar. Have you tested this before?

@wenfangdu commented on GitHub (Jun 14, 2021): @pawlos @NickeManarin No automated tasks for that (only has a default mouse-clicking task): ![image](https://user-images.githubusercontent.com/28700378/121969360-aa475980-cda6-11eb-880c-90cc7e844bcf.png) I tried cropping the recorded GIFs, works well so far. > It could also be related to issues with high screen DPI and the recorder not correctly detecting the size of the capture region. My current screen is 22.5 inches, 1920\*1200, the zoom level is 100%, so I guess that's not _high screen DPI_? The recorded GIF size is 1922\*1201 / 1922\*1202, which exceeds my screen's size, the recorder didn't correctly detect the capture region size. How to let it detect correctly when recording new GIFs in full-screen mode? Another setting that might be relevant: I use "Automatically Hide The Taskbar In Desktop Mode" for the windows 10 taskbar. Have you tested this before?

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@pawlos commented on GitHub (Jun 15, 2021):

My current screen is 22.5 inches, 1920*1200, the zoom level is 100%, so I guess that's not high screen DPI?

Yup, that's a normal one.

How to let it detect correctly when recording new GIFs in full-screen mode?

I think it should work, but TBH I very rarely us full screen recording. I'll check if there's some issue in the code in that aspect.

I use "Automatically Hide The Taskbar In Desktop Mode" for the windows 10 taskbar. Have you tested this before?

I haven't really used that one, but now I'll check if there's any issue when this is on.

@pawlos commented on GitHub (Jun 15, 2021): > My current screen is 22.5 inches, 1920*1200, the zoom level is 100%, so I guess that's not high screen DPI? Yup, that's a normal one. > How to let it detect correctly when recording new GIFs in full-screen mode? I think it should work, but TBH I very rarely us full screen recording. I'll check if there's some issue in the code in that aspect. > I use "Automatically Hide The Taskbar In Desktop Mode" for the windows 10 taskbar. Have you tested this before? I haven't really used that one, but now I'll check if there's any issue when this is on.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@pawlos commented on GitHub (Jun 16, 2021):

@wenfangdu I did some tests but couldn't observe any of the issues. Neither I get a border around frames nor did I get a bit bigger frame size. Is this behavior consistent on your setup?

@pawlos commented on GitHub (Jun 16, 2021): @wenfangdu I did some tests but couldn't observe any of the issues. Neither I get a border around frames nor did I get a bit bigger frame size. Is this behavior consistent on your setup?

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@wenfangdu commented on GitHub (Jun 16, 2021):

@pawlos Yes, I tried 2 different monitors, one is 24 inches, 1920*1080, another is 22.5 inches, 1920*1200, both reproduced the issue. I think if it's not reproducible for you, it's better to watch for the code that generates random color for GIF's background/border since it's quite special IMO.

Just did a few more tests, each full-screen recording could produce a different border color, white being the most frequent.

@wenfangdu commented on GitHub (Jun 16, 2021): @pawlos Yes, I tried 2 different monitors, one is 24 inches, 1920\*1080, another is 22.5 inches, 1920\*1200, both reproduced the issue. I think if it's not reproducible for you, it's better to watch for the code that generates _random_ color for GIF's background/border since it's quite special IMO. Just did a few more tests, each full-screen recording could produce a different border color, `white` being the most frequent.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@NickeManarin commented on GitHub (Jun 16, 2021):

@wenfangdu I have some questions.

Which recorder UI are you using? Newer or older?

What's your screen DPI? Capture something, stop, and let the editor open, then open the Statistics tab and share a screenshot.

Are the borders being created by the recorder, by the encoding process or by the upload process to the website?

@NickeManarin commented on GitHub (Jun 16, 2021): @wenfangdu I have some questions. 1) Which recorder UI are you using? Newer or older? ![image](https://user-images.githubusercontent.com/14798947/122304266-525e3f00-cedb-11eb-88df-b9dbb93abbf4.png) 2) What's your screen DPI? Capture something, stop, and let the editor open, then open the Statistics tab and share a screenshot. ![image](https://user-images.githubusercontent.com/14798947/122304409-8f2a3600-cedb-11eb-91c3-c25561915645.png) 3) Are the borders being created by the recorder, by the encoding process or by the upload process to the website?

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@wenfangdu commented on GitHub (Jun 16, 2021):

@NickeManarin Your questions reminded me, I just switched the capture mode from DirectX to BitBlt, the new GIFs being produced don't have borders now, so it's caused by the DirectX capture mode.

As for the questions:

New.
96 DPI.
By the recorder.

Can you reproduce with DirectX being on? @pawlos

@wenfangdu commented on GitHub (Jun 16, 2021): @NickeManarin Your questions reminded me, I just switched the capture mode from `DirectX` to `BitBlt`, the new GIFs being produced don't have borders now, so it's caused by the `DirectX` capture mode. As for the questions: 1. New. 2. 96 DPI. 3. By the recorder. Can you reproduce with `DirectX` being on? @pawlos

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@pawlos commented on GitHub (Jun 17, 2021):

@wenfangdu Nope. I tried with DirectX and don't see any borders - tried on regular as well as HiDPI screens, different settings on for the compression and storage (file vs memory).

Not sure if that's important but I can see that some of the examples from you image, doesn't have to bottom border set to the same color. Were they recorded somehow differently from the rest?

@pawlos commented on GitHub (Jun 17, 2021): @wenfangdu Nope. I tried with DirectX and don't see any borders - tried on regular as well as HiDPI screens, different settings on for the compression and storage (file vs memory). Not sure if that's important but I can see that some of the examples from you image, doesn't have to bottom border set to the same color. Were they recorded somehow differently from the rest?

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@wenfangdu commented on GitHub (Jun 19, 2021):

@pawlos @NickeManarin
I just noticed after I hit Window, the auto-detected capture region is 1922*1202 or 1922*1201, instead of 1920*1200, this behavior is the same for both BitBlt and DirectX capture modes, the only difference I've observed is that BitBlt always produces black border, and DirectX produces random-color border.

So technically, using BitBlt doesn't remove the border, it just sets the border to black.

And to answer:

Not sure if that's important but I can see that some of the examples from your image, don't have to bottom border set to the same color. Were they recorded somehow differently from the rest?

The bottom borders are simply not included, because sometimes the auto-detected capture region is 1902*1201.

@wenfangdu commented on GitHub (Jun 19, 2021): @pawlos @NickeManarin I just noticed after I hit `Window`, the auto-detected capture region is 1922\*1202 or 1922\*1201, instead of 1920\*1200, this behavior is the same for both `BitBlt` and `DirectX` capture modes, the only difference I've observed is that `BitBlt` always produces black border, and `DirectX` produces random-color border. ![image](https://user-images.githubusercontent.com/28700378/122628220-83ab5a80-d0e7-11eb-8f4c-c66b774e2efa.png) So technically, using `BitBlt` doesn't remove the border, it just sets the border to black. And to answer: > Not sure if that's important but I can see that some of the examples from your image, don't have to bottom border set to the same color. Were they recorded somehow differently from the rest? The bottom borders are simply not included, because sometimes the auto-detected capture region is 1902\*1201.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@pawlos commented on GitHub (Jun 19, 2021):

@wenfangdu I must have missed that you are using 'Window' mode for fullscreen recording. When I use that I do get the same issue that detected resolution is a bit bigger (2px). And when I record I have a dark border (but never yet color). I'll investigate why this might occur.

@pawlos commented on GitHub (Jun 19, 2021): @wenfangdu I must have missed that you are using 'Window' mode for fullscreen recording. When I use that I do get the same issue that detected resolution is a bit bigger (2px). And when I record I have a dark border (but never yet color). I'll investigate why this might occur.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@wenfangdu commented on GitHub (Jun 19, 2021):

@pawlos Aha! Right, I didn't realize that, because I'm using "Automatically Hide The Taskbar In Desktop Mode", Window is the same as Screen for me 😄, I'll use Screen mode in the future.

And when I record I have a dark border (but never yet color).

I got a dark border when using BitBlt and a random color border for DirectX, please try comparing both capture modes in Window mode.

@wenfangdu commented on GitHub (Jun 19, 2021): @pawlos Aha! Right, I didn't realize that, because I'm using "Automatically Hide The Taskbar In Desktop Mode", `Window` is the same as `Screen` for me 😄, I'll use `Screen` mode in the future. > And when I record I have a dark border (but never yet color). I got a dark border when using `BitBlt` and a random color border for `DirectX`, please try comparing both capture modes in `Window` mode.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@pawlos commented on GitHub (Jun 19, 2021):

OK, so it looks like DwmGetWindowAttribute(handle, (int)DwmWindowAttribute.ExtendedFrameBounds, out Rect frameBounds, Marshal.SizeOf(typeof(Rect))); returns coordinates that are a bit bigger than the window itself. Windows adds some extra stuff on top of normal size, like drop shadow or invisible frame for easier resizing but ExtendedFrameBounds supposed to be w/o any of that so it needs to be investigated more closely.

@pawlos commented on GitHub (Jun 19, 2021): OK, so it looks like `DwmGetWindowAttribute(handle, (int)DwmWindowAttribute.ExtendedFrameBounds, out Rect frameBounds, Marshal.SizeOf(typeof(Rect)));` returns coordinates that are a bit bigger than the window itself. Windows adds some extra stuff on top of normal size, like drop shadow or invisible frame for easier resizing but `ExtendedFrameBounds` supposed to be w/o any of that so it needs to be investigated more closely.

kerem commented

2026-02-26 09:32:22 +03:00

Author

Owner

@NickeManarin commented on GitHub (Jun 20, 2021):

Ahh, that makes sense now.

Custom frame windows sometimes use hacks to add drop shadows, such as Visual Studio and Visual Studio Code (your example).

In line 2198 of Native.cs, there's a hack to fix the issue with Visual Studio.
We could do the same for VS Code, but it would be nice to have a proper fix for it.

//Hack for detecting the correct size of VisualStudio when it's maximized.
if (place.ShowCmd == ShowWindowCommands.Maximize && title.Contains("Microsoft Visual Studio"))
    bounds = frameBounds.ToRect(-info.cxWindowBorders, monitor.Scale);

@NickeManarin commented on GitHub (Jun 20, 2021): Ahh, that makes sense now. Custom frame windows sometimes use hacks to add drop shadows, such as Visual Studio and Visual Studio Code (your example). In line [2198 of Native.cs](https://github.com/NickeManarin/ScreenToGif/blob/master/ScreenToGif/Util/Native.cs#L2198), there's a hack to fix the issue with Visual Studio. We could do the same for VS Code, but it would be nice to have a proper fix for it. ```cs //Hack for detecting the correct size of VisualStudio when it's maximized. if (place.ShowCmd == ShowWindowCommands.Maximize && title.Contains("Microsoft Visual Studio")) bounds = frameBounds.ToRect(-info.cxWindowBorders, monitor.Scale); ```

kerem commented

2026-02-26 09:32:23 +03:00

Author

Owner

@pawlos commented on GitHub (Jun 21, 2021):

@NickeManarin I'll see if I can come up with a bit more proper fix.

@pawlos commented on GitHub (Jun 21, 2021): @NickeManarin I'll see if I can come up with a bit more proper fix.

kerem commented

2026-02-26 09:32:23 +03:00

Author

Owner

@pawlos commented on GitHub (Jul 6, 2021):

@NickeManarin I've tried to find something that would give consistent results across different windows but failed. I'm starting to think if it's even possible to get exact window bounds. Have to pass this one :(

@pawlos commented on GitHub (Jul 6, 2021): @NickeManarin I've tried to find something that would give consistent results across different windows but failed. I'm starting to think if it's even possible to get exact window bounds. Have to pass this one :(

kerem commented

2026-02-26 09:32:23 +03:00

Author

Owner

@NickeManarin commented on GitHub (Jul 6, 2021):

It's ok. It's unfortunate that some apps like to extend beyond the bounds.
Looks like the only way to use the same hack as the one applied to VS.

@NickeManarin commented on GitHub (Jul 6, 2021): It's ok. It's unfortunate that some apps like to extend beyond the bounds. Looks like the only way to use the same hack as the one applied to VS.

kerem commented

2026-02-26 09:32:23 +03:00

Author

Owner

@pawlos commented on GitHub (Jul 7, 2021):

Looks like the only way to use the same hack as the one applied to VS.

I think this would end up being unmanageable in the long run. It's even more problematic with Win11, where (it looks like) some windows can have rounded corners and some don't. :/

@pawlos commented on GitHub (Jul 7, 2021): > Looks like the only way to use the same hack as the one applied to VS. I think this would end up being unmanageable in the long run. It's even more problematic with Win11, where (it looks like) some windows can have rounded corners and some don't. :/

kerem referenced this issue

2026-03-01 18:55:33 +03:00

[GH-ISSUE #706] Questions About Save As Shortcode #2288

kerem referenced this issue

2026-03-01 18:55:36 +03:00

[GH-ISSUE #706] Questions About Save As Shortcode #2290

kerem referenced this issue

2026-03-01 18:55:40 +03:00

[GH-ISSUE #706] Questions About Save As Shortcode #2293

Rows
Columns

[GH-ISSUE #915] [Question] Why recording in full-screen mode adds a border with random color? #706