UEZ

This creates a memory leak _WinAPI_SaveHICONToFile(@ScriptFullPath&'.ico', _GDIPlus_HICONCreateFromBitmap($bmp)) _GDIPlus_HICONCreateFromBitmap($bmp) creates HICON without being released. Suggestion: Func seticon() Local $hIcon = _GDIPlus_HICONCreateFromBitmap($bmp) _WinAPI_SaveHICONToFile(@ScriptFullPath&'.ico', $hIcon) _WinAPI_DestroyIcon($hIcon) TraySetIcon(@ScriptFullPath&'.ico') FileDelete(@Scriptfullpath&'.ico') EndFunc You should create your animation frames in the memory rather than writing it permanetly to disk and loading it from there again. PS: I didn't test your code - only visual checked.

Yes because you add _GDIPlus_PathAddPolygon($hPath3, $aPoints3) which is not equal to the first figure above. Try $hPen2 = _GDIPlus_PenCreate(0xFF000000, 1) and you will see an additional border which doesn't exist in 1st figure.

@wakillon I changed the Settings GUI to DarkMode. It should work now for you, too. You have to download it again -> ScreenRecorder.7z

GraphicsCaptureWrapper is a C++ wrapper using WinRT and DX11 to provide the desktop image to the encoder.

Ok, you are not drunken. 😉😄 I'm working on fixing the problem. Thanks for testing. I wonder if others have the same problem...

Well, if the background is light, it can be even harder to read the values in the input fields. But when I open the GUI on a white background, I can still see the numbers fairly well. Maybe it’s because I don’t have a 4K monitor and can’t reproduce your problem. Since desktop recordings can get quite large and are recorded internally in high444 format—which not every video player can play—you can easily use FFMPEG to reduce the size of the AVI file and make it compatible so that even the default Windows tools can play it! Example in CMD: ffmpeg.exe -i Capture_20260426_181055.avi -c:v libx265 -crf 32 -pix_fmt yuv420p -preset medium output_small.mp4

I assume that sending frames to the encoder is taking too long, which prevents the target FPS from being reached, causing the video to play back faster (frame dropping due to hardware encoding bottlenecks at 4K @ 60 FPS.). It’s also possible that the encoder can’t process the volume of data at 60 FPS. You may try the "ultrafast" setting, default is "veryfast" and set to 30 FPS. Unfortunately, these are the limitations of this setup involving screen capture (CPU -> GraphicsCaptureWrapper DLL) and an x64 encoder (x264 DLL). It is very likely that only code based on a hardware encoder (GPU) can handle this load without frame drops. At 4K resolution and 60 frames per second, the CPU has to process about 500 million pixels per second.

Can you please give me following information fullscreen capture? if yes, which resolution? is DPI > 100%? how did you measured the time difference? I called SetProcessDPIAware() that might be the reason for the DPI scale. Tomorrow I can test in my office on 3 monitor environment.

I meant ScreenRecorder.7z (GUI version). vfw is no longer being developed (links are dead).

@wakillon I updated the code. Can you please download the new version and test it again? I uploaded the GraphicsCaptureWrapper64.dll v0.5.1 which works for Region capturing. There is a problem with new version... Merci.

Yes, I can reduce transparency. When the background is dark it looks nice but on brighter background it becomes harder to read. Let me check if it is possible to get the recording time rather than a parallel timer. Obviously Windows cannot play AVI file because of missing decoder for H264 - MPEG-4 AV (part 10) (h264) (same on my Win11). You can use VLC Player, MediaPlayer Classic or any other app which supports this codec. Thanks for testing. 👍 Btw, defaults are 30 fps and Region doesn't work properly yet because of some unknown stride settings...

@wakillon thanks for testing. vfw is now replaced with x264 dll. @All: Can you please test: ScreenRecorder.7z It is now GUI driven. Limitations: 2GB AVI file and Windows10+.

Case $WM_ERASEBKGND Return 1 This means you're telling Windows not to delete the background, because we've already done that. May flicker when removed. Case $WM_SETFOCUS, $WM_KILLFOCUS These messages appear when you click in the field or move away from it (e.g., by pressing the Tab key). Case $WM_MOUSEMOVE / $WM_MOUSELEAVE This is the logic behind the hover effect (the frame lights up when the mouse hovers over it). _WinAPI_InvalidateRect is basically the “Redraw, please!” command for Windows. If everything works fine without the Case checks, you can leave them out, but this may vary depending on the operating system. I haven't noticed any negative effects without that parts.

1) As a general rule, when you open a resource, you should release it again to avoid a memory leak. For example, if you constantly call _WinAPI_CreateSolidBrush(), you’re reserving memory without freeing it up. Eventually, the memory will run out. Yes, every call to _WinAPI_CreateSolidBrush() / _WinAPI_DeleteObject() takes processing time, which may become noticeable if there are a large number of calls. I don’t think this plays a major role for “normal” applications. 2) At first glance, it appears that no brush is being used, but I assume that Windows creates a brush internally and then deletes it to prevent a memory leak.

Use BGR values to set color directly $tNMLVCUSTOMDRAW.clrTextBk = 0x60004A ;indigo $tNMLVCUSTOMDRAW.clrText = 0xFFFFFF