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

[wenfangdu]

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.

[pawlos]

@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.

[NickeManarin]

@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.

[wenfangdu]

@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?

[pawlos]

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]

@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?

[wenfangdu]

@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.

[NickeManarin]

@wenfangdu I have some questions.

1) Which recorder UI are you using? Newer or older?

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

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

[wenfangdu]

@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

[pawlos]

@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?

[wenfangdu]

@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.

[pawlos]

@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.

[wenfangdu]

@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.

[pawlos]

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.

[NickeManarin]

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);

[pawlos]

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

[pawlos]

@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 :(

[NickeManarin]

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.

[pawlos]

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. :/