UEZ

Indeed _GDIPlus_ImageAttributesDispose($hIA) is missing in _GDIPlus_ImageResize() after / before _GDIPlus_GraphicsDispose($hBmpCtxt), which can lead to memory leaks when called multible times. @jpm can you fix it please?

Func _GDIPlus_ImageResize($hImage, $iNewWidth, $iNewHeight, $iInterpolationMode = $GDIP_INTERPOLATIONMODE_HIGHQUALITYBICUBIC) Local $iWidth = _GDIPlus_ImageGetWidth($hImage) If @error Then Return SetError(1, 0, 0) Local $iHeight = _GDIPlus_ImageGetHeight($hImage) If @error Then Return SetError(2, 0, 0) Local $hBitmap = _GDIPlus_BitmapCreateFromScan0($iNewWidth, $iNewHeight) If @error Then Return SetError(3, 0, 0) Local $hBmpCtxt = _GDIPlus_ImageGetGraphicsContext($hBitmap) _GDIPlus_GraphicsSetInterpolationMode($hBmpCtxt, $iInterpolationMode) _GDIPlus_GraphicsSetPixelOffsetMode($hBmpCtxt, $GDIP_PIXELOFFSETMODE_HIGHQUALITY) Local $hIA = _GDIPlus_ImageAttributesCreate() __GDIPlus_ImageAttributesSetImageWrapMode($hIA) If @error Then _GDIPlus_ImageAttributesDispose($hIA) _GDIPlus_GraphicsDispose($hBmpCtxt) _GDIPlus_BitmapDispose($hBitmap) Return SetError(4, 0, 0) EndIf _GDIPlus_GraphicsDrawImageRectRect($hBmpCtxt, $hImage, 0, 0, $iWidth, $iHeight, 0, 0, $iNewWidth, $iNewHeight, $hIA) _GDIPlus_GraphicsDispose($hBmpCtxt) Return $hBitmap EndFunc ;==>_GDIPlus_ImageResize Func _GDIPlus_ImageScale($hImage, $iScaleW, $iScaleH, $iInterpolationMode = $GDIP_INTERPOLATIONMODE_HIGHQUALITYBICUBIC) Local $iWidth = _GDIPlus_ImageGetWidth($hImage) If @error Then Return SetError(1, 0, 0) Local $iHeight = _GDIPlus_ImageGetHeight($hImage) If @error Then Return SetError(2, 0, 0) Local $iNewWidth = $iWidth * $iScaleW Local $iNewHeight = $iHeight * $iScaleH Local $hBitmap = _GDIPlus_BitmapCreateFromScan0($iNewWidth, $iNewHeight) If @error Then Return SetError(3, 0, 0) Local $hBmpCtxt = _GDIPlus_ImageGetGraphicsContext($hBitmap) _GDIPlus_GraphicsSetInterpolationMode($hBmpCtxt, $iInterpolationMode) _GDIPlus_GraphicsSetPixelOffsetMode($hBmpCtxt, $GDIP_PIXELOFFSETMODE_HIGHQUALITY) Local $hIA = _GDIPlus_ImageAttributesCreate() __GDIPlus_ImageAttributesSetImageWrapMode($hIA) If @error Then _GDIPlus_ImageAttributesDispose($hIA) _GDIPlus_GraphicsDispose($hBmpCtxt) _GDIPlus_BitmapDispose($hBitmap) Return SetError(4, 0, 0) EndIf _GDIPlus_GraphicsDrawImageRectRect($hBmpCtxt, $hImage, 0, 0, $iWidth, $iHeight, 0, 0, $iNewWidth, $iNewHeight, $hIA) _GDIPlus_ImageAttributesDispose($hIA) _GDIPlus_GraphicsDispose($hBmpCtxt) Return $hBitmap EndFunc ;==>_GDIPlus_ImageScale I can see it in both functions. 😉

With resize I mean really resize of the grid. My example above fills only the grid but doesn't resize it. You can also resize the grid when GUI resizes. That means the grid becomes smaller / bigger on GUI resize.

Is the grid just for demonstration purposes, or is that really the background you want to use? Should the grid resize when the GUI is resized? Here the version without resizing the grid on GUI resize (modified one of my old scripts): ;Coded by UEZ build 2026-05-31 #include <Constants.au3> #include <GDIPlus.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> Global Const $STM_SETIMAGE = 0x0172 Global $sImage = "Grid.png" _GDIPlus_Startup() Global $hBmp = _GDIPlus_BitmapCreateFromFile($sImage), $hTexture = _GDIPlus_TextureCreate($hBmp, 0) Global $iW = _GDIPlus_ImageGetWidth($hBmp), $iH = _GDIPlus_ImageGetHeight($hBmp) Global $hGUI = GUICreate("Test", $iW, $iH, -1, -1, BitOR($GUI_SS_DEFAULT_GUI, $WS_SIZEBOX, $WS_THICKFRAME), $WS_EX_COMPOSITED) Global $idPic = GUICtrlCreatePic("", 0, 0, $iW, $iH) GUICtrlSetResizing(-1, $GUI_DOCKAUTO) Global $hHBitmap = _GDIPlus_BitmapCreateHBITMAPFromBitmap($hBmp) Global $hB = GUICtrlSendMsg($idPic, $STM_SETIMAGE, $IMAGE_BITMAP, $hHBitmap) If $hB Then _WinAPI_DeleteObject($hB) GUISetState(@SW_SHOW) GUIRegisterMsg($WM_SIZE, "WM_SIZE") While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE GUIRegisterMsg($WM_SIZE, "") _WinAPI_DeleteObject($hHBitmap) _GDIPlus_BrushDispose($hTexture) _GDIPlus_BitmapDispose($hBmp) _GDIPlus_Shutdown() GUIDelete() Exit EndSwitch WEnd Func WM_SIZE($hWnd, $Msg, $wParam, $lParam) #forceref $Msg, $wParam, $lParam Local $aSize = ControlGetPos($hWnd, "", $idPic) Local $hBitmap = _GDIPlus_BitmapCreateFromScan0($aSize[2], $aSize[3]) Local $hContext = _GDIPlus_ImageGetGraphicsContext($hBitmap) _GDIPlus_GraphicsSetInterpolationMode($hContext, 0) _GDIPlus_GraphicsFillRect($hContext, 0, 0, $aSize[2], $aSize[3], $hTexture) _GDIPlus_GraphicsDispose($hContext) Local $hHBitmap = _GDIPlus_BitmapCreateHBITMAPFromBitmap($hBitmap) Local $hB = GUICtrlSendMsg($idPic, $STM_SETIMAGE, $IMAGE_BITMAP, $hHBitmap) If $hB Then _WinAPI_DeleteObject($hB) _WinAPI_DeleteObject($hHBitmap) _GDIPlus_BitmapDispose($hBitmap) Return "GUI_RUNDEFMSG" EndFunc

I found the bug: I changed from CoInitializeEx(NULL, COINIT_MULTITHREADED) to CoInitializeEx(NULL, COINIT_APARTMENTTHREADED). WGC (Windows.Graphics.Capture) is based on WinRT, and WinRT objects are fundamentally designed for MTA. Bug should be fixed know.

Sorry, there is a nasty bug in 0.7.7.0 -> when you start, stop and start again it crashes... 🤔

Done.

Thanks for the complete set of logs! Here's the full picture across all four configurations: All recordings have the correct duration — no more drift, the file matches real time in every case. 4K @ 30 fps with High 4:4:4 is the best setting for your system — lowest drop rate (23%) and almost no duplicated frames (7%). This gives you the cleanest capture. Interestingly, switching to High 4:2:0 doesn't help — it actually increases drops and dupes. That's because 4:2:0 forces an extra color conversion step (BGRA→YUV) inside x264 which costs additional CPU time, while 4:4:4 takes the raw pixel data directly with no conversion overhead. 4K @ 60 fps stays limited to ~30 real frames per second regardless of profile — this is a WGC API throughput ceiling on your hardware, not something AirCapRec can work around. Good catch — it's counterintuitive but makes sense once you look at the logs: At 60 fps, about 60% of your frames are duplicates (WGC only delivers ~30 real frames per second). x264 is very efficient at encoding duplicate frames — a P-frame that says "nothing changed" costs almost zero bytes. So 60 fps = lots of near-free frames. At 30 fps, nearly every frame is a unique capture with real pixel changes. Each frame needs significantly more bits to encode. So 30 fps = fewer frames but each one is expensive. Result: 30 fps × high bits per frame > 60 fps × many near-zero-cost duplicates. This is actually a sign that things work correctly! Regarding saving settings on exit — good idea, it's on the list for a future version.

Hmm, I think you used “High 4:2:0” (which is now the default setting), which converts the RGB colors to YUV colors when recording in 4K resolution. This uses too much CPU which drops a lot of frames. Was the FPS most time below 60 FPS when you look at the GUI which shows the current FPS / destination FPS. There should be a difference if you record in "High 4:4:4" at 4K @ 60 FPS. Can you test it please? How is “High 4:2:0” in 4K @ 30 FPS? I updated several times the Zip archive and in of the version I didn't use performance compiler setting. If the Exe is less than 410.000 bytes than you have the default compiled version. Merci. Edit: I tested “High 4:2:0” at 60 FPS in full HD and recorded 30 seconds. No problems and properly played in VLC, MPC-BE, Windows Media Player Legacy. Unfortunately, no other users are currently participating in the testing. 😞 Edit2: seems not to change to "High 4:4:4" when selected. Edit3: High 4:2:0 was hard coded -> fixed now. Edit4: new version uploaded -> frames will be duplicated when CPU is too slow.

Also the region? I've added support for the YUV color space (now the default), which does use a bit more CPU power, but this should allow older versions of Windows Media Player to play the files, and the MP4 file should also be a little smaller. I don't know how 4K @ 60 FPS recording works with YUV, or if there are a lot of frame drops. Thanks again for testing. 👍

@wakillon I think I fixed the DPI issues which caused that you can't see the About window and the region selection. For region: it was set to DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 and for me it works propely. Obvously your Windows version doesn't support it - added some fallbacks. I uploaded a new build -> AirCapRec (link is the same). Can you please test again?

What a shame that it's not showing up on your screen. It is the About Window with some raymarched animation and a simple vertical scroller. The About window video: About AirCapRec Window I need to check. Unfortunatelly I don't have a 4k monitor to test with 300% DPI. It takes up a lot of CPU time if you have to reduce the resolution while recording. I'm currently working on another DLL to re-encode the recorded mp4 file afterward and make it smaller. Let me analyze your log.... Thank you so much, again and again, for testing the app. I really appreciate it. 👍 Latest version on my OneDrive: AirCapRec which from today. 😉

Hi everyone, I’ve updated my video recording tool, now named AirCapRec (v0.7.5). I need help testing technical edge cases where manual stride handling often fails. Seeking feedback on: "Weird" Resolutions: Any skewed/slanted images on ultra-wide or non-standard window sizes? High-DPI / Multi-Monitor: Does the capture area and cursor align correctly at 125% or 150% scaling? Stability: Any frame drops or stutter during long sessions? Download: AirCapRec.zip If you find a bug, please post your Resolution, DPI Scaling, and Windows Version. You can also enable the Debug Log option in the settings to provide more information. Thanks for the support!

It looks good to go with. Well done!

I modified the example. I don't know if it fits now to your needs...