Kas Ob.

TNLCursor leak is easy to find and fix { .. Cursors : array[1..CURSOR_TYPES] of TNLCursor; .. procedure TGameWindow.InitializeCursor; ... begin ... for i := 1 to CURSOR_TYPES do begin Cursors[i].Free; Cursors[i] := TNLCursor.Create(LocalMaxZoom); procedure TGameWindow.FreeCursors; var i: Integer; begin for i := 0 to Length(Cursors)-1 do // will leak also it could cause AV, yet it seems never did Cursors[i].Free; end; } procedure TGameWindow.FreeCursors; var i: Integer; begin for i := Low(Cursors) to High(Cursors) do // right way Cursors[i].Free; end; The unknown need to be known to be fixed, and i don't have a crystal ball. This unknown might be very similar though, enabling Overflow Checking and Range Checking in the project option should prevent bugs and leaks like the above from first run, but i will guess here it never being enabled, and might be huge task to fix all the exception that will raise, none the less enabling them at least when debugging or developing will yield better code quality with less memory leaks.

I remembered the worse of them all, clicking show Desktop aka minimize everything, and an application still there, most annoying thing, sadly the Delphi debugger do this without any sense of consideration i would love to see an animation like a hammer and a nail when it refuse to minimize.

No imagination here just logic an make sense. OK, but how it is more complicated, on one hand Sleep doesn't have fixed interval ! right ? any other application running on Windows OS can ruin your timing by 16 fold, i saw it 1ms and saw it 15.625ms, these are the most popular. On other hand either that animation is slow and taking long time or very fast, in both cases a timer or background thread will be more appreciated and will not prevent the used from closing the app as as example or not clicking a button, or even worse buffering few clicks form the user then fire them afterward like machine gun. And again if it is one animation then one timer will do it, but if there is more then what more sleep calls, or the same one timer or even more timers, for me this is simple question and simple answer. 300ms delay in IDE autocomplete does feel very different from 200ms, don't you agree ?

Also i didn't say this will solve the problem or will work as workaround. Sleep can no be used for timing anywhere, and in this application if it is being used as such then a confirmation is needed. Just like handling Windows control and custom drawing, as example, take Custom Draw events, like ListBox, some might implement to draw one item on every call or even draw the whole list with all the items, still the OS will send punch of draw messages, different messages for might be one or many items, some will simply pointing the X item is not selected followed by Y item selected, while the application just draw the lot twice.

I do understand. I want the CPU to spike first, go full core, only after that the reason(s) for the stuttering can be identified or isolated, right now and until now all i got from the description is the CPU is doing nothing yet there is unresponsiveness in UI, after unhinge the CPU and processing loops without break, if the stutter still exist then this will mean a thing if not then it is a different thing and so on. If it is an one-to-one import for very old design like DOS then timing is suffer as modern OS and CPU behave differently and multitasking is shared responsibility between the application and OS, in old days your game should time the rendering and the input and give no concern about OS or other any applications running on the device. When i see a comment in the source right before Sleep(1) call with " // Relax CPU" then many variation comes to mind, relax for whom or to whom as this game is one thread and the OS will switch it when he see fit not waiting for such a sleep, this makes sense if such sleep is inside a never ending loop, is it ? All in all, i can't imagine (what ever) reason to call Sleep from main thread. think about it.

Well said and well done but this : This is freaking beautiful, nice. Yesterday only i downloaded https://github.com/ericlangedijk/Lemmix at last and tried to build it, but it is not for older Delphi. This is tricky sometimes, but in your case it is very easy, in that PE tab there is Starting Address, pointing to the module created the thread, in your application there is only one started form your EXE, while when debugging in the IDE yes most likely it is the first one unless an imported DLL invoked one and the debugger captured it, Delphi Debugger leave the threads sorted as they being seen, while Process Explorer sort them by CPU usage by default, and its sort options doesn't have running time. That is not exactly what i said, i said BASS is capable to do all its operations in asynchronous, but only if told to do so, the documentation clear about threading like this not so special case ( from https://www.un4seen.com/doc/#bass/BASS_ChannelSetSync.html ) But now and reading more of BASS documentation i don't think it is the culprit here, because i am sure you did disable all the sound effect if there is any changes then you would already mentioned that. Now to the most important question Well evidently is not, and your application has one thread (main one) and from PE it is doing nothing, yet it is not responding in time, so what ? This project is half doomed to work on modern OS and that is by design, after reading the readme which is clearly is pointing that the structure based on DOS era application, where you must not let the thread go anywhere except looping over handling UI and draw/update the screen. There is huge misconception in this approach with assuming to be working on modern OS, from what caught my eye the application is abusing ApplicationIdle to process almost everything, like this I want to suggest something might be look stupid and might be in fact a stupid thing considering i can build or debug or investigate this deeper, but please try the following: 1) Make sure there is no Sleep calls at all ! everything single one of them , these you have to replace them with timers in needed 2) The core problem is this class and how it does lose control and regain it, when sleeping or out of execution there is no update and when it is activated it is doing small update step just to go into sleep again, (again and again sleep is the problem) 3) put a timer on where application idle or that TIdle is used and make it call the according "Application_Idle(Sender: TObject; var Done: Boolean)" manually instead of depending on the VCL library to do so, this means disabling the handler or work around it, then though it should at least show some CPU processing and greatly raise your FPS in your case the application UI responsiveness. Sender not used so you can fill it with nil, as for Done don't process it for first test, not sure if it should be useful at all, i mean even if an animation is done drawing and we can't(and must not) disable the timer as we emulating OnIdle so calling again is merely a simple check. 4) put these timers intervals at 1 ms, start there to see how animation are being drawn, tweaking this is most likely needed but lets find and understand the structure and logic first. Share your result with us ! ps: i can't say for sure about this TIdle, but there is something wrong about it and about having Application.OnIdle being assigned in few other places other than that TIdle, so there might be some conflict or miss handling, so try to replace the Idle handlers one by one , start with the working ones, just to understand the effect and side effect.

You missed attaching this image as explanatory material Joking aside : How to use a script to add datetime on checkin like leaving the rversion 0 or whatever to minimize breaking changes, but with an extra string like 202405281850 ? Is that is easy/feasible with SVN ?

This indicate long process and from the memory graph there is huge allocation(s), but no CPU spike also no spike in IO, this means the process or the main thread was waiting or sleeping, aka doing nothing. While this is concerning, Context Switches at 272k with 3 seconds of User Time, this is too much of thread switching while the code in user mode. See this is my ThunderBird (an old version before switching to Chromium means it is single process) , It was up and running for 6 hours and still doesn't have that much of switching while in CPU cycles used as half of the shown in your screen shot. I asked for 2 different shots to compare with some interval between them, so we can see if these context switches as still happening or stopped after loading the form, and fortunately your screenshot landed on your app main thread, which i didn't explicitly point it to fearing of spending time explaining stuff might not be relevant here, so if you will repost screenshot make sure to select that thread from your EXE. ps: if you will repeat the screenshot then first run Process Explorer as Administrator, i would helpful to see the kernel time. Anyway, and to what i do see: Your application is literally doing nothing, there is no intensive CPU usage at all, but there is two background threads i am concerned about, one from dsound usaualy indicate the directsound is playing or recording, in other words there is an audio operation in work. one from BASS.dll, but not sure about this as i am not familiar with bass, only general and past knowledge, so it might be relevant to the above or might not be. from the above i have a question : Are you playing sound(s) in the background or on mouse movement events ? (are you playing sound effects ?) What ever is the answer, try to stop all audio operation like playing sounds and see how does that impact the responsive of your UI, and please share your finding. One more point : to my knowledge BASS library is fully equipped with background threads handling/playing, so most its operations can be asynchronous, to me your unresponsiveness UI is a symptoms of long synchronous operations called from MainThread, the one that should not be doing much other than handling user input, UI, and essential OS calls/notifications, and of course drawing/updating UI (this drawing is more like slapping already rendered image on a canvas).

That depends if you are doing some drawing, updating some visually elements... in other words if the updating the scroller is more than painting already cached images or change position of already ready to draw elements then use a thread to do it, then use the timer to do the paint or the update, but in both cases timer will solve your problem. Main thread is the first thread in your application the one handed the execution form OS starting the dpr code, and called Application.Run, this one is the only one should handle all your UI (VCL/FMX) and their events, MainThread is a name for specific thread and not some generic terminology. Also keep in mind that your MainThread is the one responsible for any stuttering or slow UI handling, so we need to free it from doing anything expensive or might take long time, its job is answering OS messages (aka user and OS input and your specific requests from the OS)as fast as possible, when that is full filled the UI will be smooth, fast and keep up with screen refresh rate. You could share your CPU usage as it might indicate the problem, is it too much work or too much sleep and wait ? To do that, use Process Explorer from Sysinternals, then double click on your application, in that properties window, take screenshot of two tabs, and another screenshot for the following tabs after some time passed like 1 minute or more: Threads Performance Graph These tabs might help identifying strange or wrong behavior or at least will give an insight of the performance in overall.

OK, But evidently your application usage of Sleep is showing a problem if understanding its impact, see, Sleep(1) aka sleep for 1 millisecond by default will be 1000/64=15.625 ms, limiting that specific path of code to 64 time per second, this will affect UI greatly, so : 1) Search for every Sleep call in your project from the main thread and remove them, don't use Sleep in main thread not for 1 or even 0 ms, they makes no sense, for background thread it is understandable and useful, but again if the main thread will wait for background thread to finish rendering an animation to paint it then again UI will behave as you described. 2) In my life i may be have used ApplicationIdle few times that can be counted on hand, mostly were to logout or clean up and close stuff or finish opened procedure to not causing blocking something online, but i have removed tens of these handlers from projects that are not mine, due the abuse and misunderstanding of usage, ApplicationIdle is healthy way to see that your UI is responsive the more is called the better, and never use it for something take long time, if needed then start background thread to do it. 3) Your animation most likely is the cause, this is my guess, a thread is doing something while main thread is waiting on it to paint, that is wrong approach, let the thread render (prepare what ever), on other hand use a timer, simple timer with adequate interval to see if that thread or the animation is ready to be painted then draw/paint it, and exit, don't use interval higher than 60 per second, as this is useless and waste of time, on other hand try to centralize all your animations with one timer and one class that do the draw/paint, you don't need every animated button to use 60 message per second, right ? because this will starve UI from handing message and produce the mentioned behavior.

You are calling Sleep(interval) in GameScreenMenu.TGameScreenMenu.ApplicationIdle , this interval either too big or being called too many times behaving like deadlock. the problem is not exactly there, but in some sort of combination with waiting on some event or value from the TGameBaseMenuScreen, as this one is in DoLevelSelect is executing ShowModal . So your ShowModal is implemented in the base class while you ApplicationIdle is in the inherited one, now make sure you are not checking on any Form.Handle as it might be recreated in other words, your ShowModal form might be not visible or lost track of some of its internal fields where your Idle handler is waiting on it. Suggestion : 1) redo or completely remove that Idle handler, by redo i mean re-code it in defensive way assuming you can't trust any locally stored values and check them at runtime every time you evaluating something namely and most critically before calling a Sleep, 2) Why on earth you need to call on Sleep to begin with ? if you step back to look at what is going on, OnIdle is executed when the application is Idle and no work to, but you are introducing a work for it by calling Sleep !!

I have no idea why i wrote "doesn't".

It doesn't help.

I used ApiMonitor to track this behavior, the result of all clipboard functions called for MMC.exe : One function in particular is the culprit so i tested it and found SetClipboardViewer(0); // invalid handle here This will trigger sending WM_CLIPBOARDUPDATE to all registered handlers, mmc is calling it, i think many of these system administration tools will call it too. Save the clipboard content or part of it and compare for changes on every WM_CLIPBOARDUPDATE.

Most likely you can, but just for editing files, it is easier to use Notepad++ than Delphi to edit JavaScript and HTML, from https://developer.kaiostech.com/

You nicely summarized the good, the bad and the ugly in spawning console processes. My thoughts here: 1) The role of thumb for console application to be terminated at any time, and these signals or ControlEvent are not to reliable to be depends on, yet there is some cases where they are needed to not lose some job or as you named it gracefully terminate. 2) as for application you pointed to wstcp, i don't see any such event handler in the source, (may be i missed something) but you can check for your self https://rust-cli.github.io/book/in-depth/signals.html 3) As for your own processes then i suggest to try different IPC than standard console pipe, like Memory Sharing, it will give you better speed, like you can use background threads to wait on events or simply let the spawned processed write to the named shared memory passed to them in a command line and the mother process will check with intervals and read ... remember there nothing prevent a spawned from allocating shared memory too for lets say specific temporary file or stream of data and put the name in predefined table which also shared but from the owner process and passed to the child... anyway there is many approaches to handle this, and they all will remove the need the dependency on events like CTRL+C 4) if you not sure if the 3rd party process does require graceful termination then don't use TerminateProcess, make sure all your other process handle such event and either refuse to close or terminate too, but again you need to tell them first through some IPC that an event is coming and should be ignored. Again for that "WebSocket to TCP proxy" it is fine to use terminate process. All the concerning points in ExitProcess are for a process calling ExitProcess itself and it is recommending to switch to TerminateProcess for the case where the same process is not sure if it has a thread locking a detaching DLL callback function, so TerminateThread is safer and should be in mind when designing an application. Also notice my suggestion above for using shared memory and wait can be the worst because of if an application is built to wait on some value in memory shared then TerminateProcess will put the waiting process in deadlock, hence you should a thread to poll the value and not wait, or wait on an event, created by the child process hence the Exit/Terminate will signal it.

Well, creating self signed certificate for code signing is easy as the certificates for key exchange certificates (aka SSL/TLS), it is in the Extended Key Usage defined by OID against BUT , both above are end certificates and not self signed, and code signing by self signed is no-no for any AV or for SmartScreen for many reason 1) the best practice is to have SelfSigned which will be called root that allow to issued and sign CA or end certificate, am talking out of debugging for developers, out of debugging certificates should never be a self signed. 2) Such self signed and any signed certificate signed (issued) by it (CA and end) must have a way to be revoked, this will bring whole different beast to the table, the certificate must have OCSP and/or CRL server that answer for the validity for this certificates, such server must also time stamp with signature its response, CRL and OCSP are fields in certificate with according OID and specific format, CRL response should be signed by the selfsigned while OCSP is really complex response. Sorry for the extended details, but i think it might be useful for some.

@Patrick PREMARTIN , that is very kind and nice, my certificate will expire in a month and would offer to sign useful and needed binaries but not for open source that easily can be build by the same IDE will use it, still it is disturbing to see Embarcadero as chain supplier supply signed code not built by them, again this might be useful for hard to build binaries or closed source projects. First half is somehow fine, the second is NOOOOOOOOOOOOO Don't ever add certificates to your OS trusted store at a whim or for one single binary. The most lethal attacks is the ones that violate trust chain, see, any application you are running on your PC with elevated privileges might/can add trusted certificate, silently, a lethal stage for next part of the attack form different binary that you might download and click, and this time nothing will detect it or stop it. As for Embarcadero then the proposed of self signed or lets say self issued certificate might work, but it should not be in the OS store, it should be in the IDE and only the IDE -well in this case GetIt- will validate that certificate and execute the binary after confirming it is from Embarcadero, that works, it must parse the certificate and run it on its own, then either by notify you it is OK to pass SmartScreen or use a DLL version of the installer and execute it with its privileges, so no OS complains. @dummzeuch Thank you, and no one should ask you to be responsible for securing an an open source project, or waste time and money on that.

I just don't get it !?? WHY ? The source is there, and i only can imagine the amount of the hours and work went into it to make it compliable as simple as few clicks, it is not like you need the compiled version for Microsoft Office PowerPoint. Just download the god damn repository (the source) and build it. For the binary from GetIt (not sure if it is there) then it is Embarcadero responsibility to build it and sign it, aka making it trustable. And that it is. Having the source and build it will make it better by ensuring bugs and mistakes are fixed in time and a call to every user to engage in the project.

Also i am failing now to write one good example to show that behavior with XE8.

I disagree with this statement, Delphi compiler uses the stack (indexed access) always when ran out of register with optimized enabled or disabled (in case disabled it always will depend on them), in case very simple local procedure then yes there might be an overhead due the need for register for the parent hence will switch for indexed stack access ( slower or lets say overhead), but in most cases local procedure are used to decrease complexity and increase readability, this infer the high local variables used then most likely the parent is already using the indexed stack access for most of its local variables, introducing the local procedure/function in this case might give the compiler the ability to use the register again specially in case moving loops to local procedures hence increasing the speed even with the few stack preparing overhead instructions, So i don't i agree with that statement, it is relative to some degree and based on the case of the usage, again with complex procedures with more than one loop or even nested ones, extracting some of the code to local procedure might be useful mostly for readability, decrease complexity, and might enhance the performance, but who knows how the compiler will behave, in many cases rearranging the local declared variables order can enhance the performance when the compiler use registers for the first encountered variables, hence using or switching the variables order might yield better performance but this will not help the local procedure with loops always, specially if it is was stack accessed to begin with, and the compiler lost the track or simply overwhelmed with variables or the code. Also lets not forget that parameters passed to the parent p/f are already in registers so the chance to lose registers usage for local variables is already amplified greatly.

I know this very same behaviour for many years, the chance to happen is great when adding/removing package or projects from projects group using Project Manager using drag and drop then removing, there other cases too which can't say for sure but renaming some shared unit between packages or projects while these projects are grouped might cause this corruption, confirmed on D2010 and XE8. And to confirm this has nothing to do with line endings or anything on user part editing the dpr, the projects is saved and not even opened in the IDE, the project is compiling fine, then something happen and the compiler point to "rrequires" in dpr ??, undo there on that dpr doesn't work too, IDE had broken parser there, even when it should not edit that specific dpr ad rewrite it in full with broken few keywords.

I don't have the equipment to debug or deep dive in this subject, but from this I want to point something and hope it is not waste of time, What about synchronizing objects here ? , how many are there ? what are they ? are they critical sections or something else? See, returning data form GPU done by either blocking or waiting, but in fact in both cases internally they are hardware interrupts triggers, so the derivers plays a role and if there is a waiting mechanism. So, i would suggest to Rene to count these and if possible (of course in case there is many) on FireMonkey side to replace each and every one of them (aka patch someway or another) to be a spinlock, that spin with : 1) try to spin for 50k-100k loop in place before reduce the spin speed by SwitchToThread or Sleep(0). 2) tweak the range 50k-100k up and down and see the impact on FPS. 3) Use Sleep(0) and SwitchToThread without spinning in place. also how many objects really are being sent to the GPU, (data or whatever), compared to haw many render call on FMX layer per object, a ratio would help here. There was a bug or inefficiency in AlphaSkins, where paining a control needed its parent and this caused the parent to render all of its control on it and this triggered many render with each paint escalating or amplifying the CPU usage on main thread and that made it stutter. Here my AS demo it might help with more accurate or easier way to track this behavior with FMX CustomDraw.rar The is simple, these boxes should show 10 as 10 FPS objects to be rendered no more and no less. In all case sorry if this post is a waste of time.

@Clément Try this non blocking refined code with leakage : unit uTCPPortCheckNonBlocking; interface uses Windows, Winsock2; function WSAInitialize(MajorVersion, MinorVerion: Integer): Boolean; function WSADeInitialize: Boolean; function CheckTCPPortNB(const IP: string; Port: Integer; out TimeMS: Integer): Boolean; var CHECKPOINT_TIMEOUT_MS: integer = 1000; implementation function CheckTCPPortNB(const IP: string; Port: Integer; out TimeMS: Integer): Boolean; var s: TSocket; Addr: TSockAddrIn; SAddr: TSockAddr absolute Addr; QPF, QPC1: Int64; NonBlockMode: DWORD; Res: Integer; FDW, FDE: fd_set; TimeVal: TTimeVal; function GetElapsedTime: Integer; var QPC2: Int64; begin QueryPerformanceCounter(QPC2); Result := (QPC2 - QPC1) div (QPF div 1000); end; begin Result := False; TimeMS := 0; s := socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if s = INVALID_SOCKET then Exit; NonBlockMode := 1; ioctlsocket(s, Integer(FIONBIO), NonBlockMode); Addr.sin_family := AF_INET; Addr.sin_addr.S_addr := inet_addr(PAnsiChar(AnsiString(IP))); Addr.sin_port := htons(Port); QueryPerformanceFrequency(QPF); QueryPerformanceCounter(QPC1); Res := connect(s, SAddr, SizeOf(SAddr)); if (Res = SOCKET_ERROR) and (WSAGetLastError = WSAEWOULDBLOCK) then begin TimeVal.tv_sec := 0; // 1 sec = 1000000 usec TimeVal.tv_usec := 1000; // 1 ms = 1000 usec repeat FDW.fd_count := 1; FDW.fd_array[0] := s; FDE.fd_count := 1; FDE.fd_array[0] := s; TimeMS := GetElapsedTime; Res := select(1, nil, @FDW, @FDE, @TimeVal); until (Res > 0) or (TimeMS >= CHECKPOINT_TIMEOUT_MS); end; Result := (FDW.fd_count = 1) and (FDE.fd_count = 0); TimeMS := GetElapsedTime; if s <> INVALID_SOCKET then closesocket(s); end; function WSAInitialize(MajorVersion, MinorVerion: Integer): Boolean; var WSA: TWsaData; begin Result := WSAStartup(MakeWord(MajorVersion, MinorVerion), WSA) = 0; if Result then begin Result := (Byte(WSA.wVersion shr 8) = MinorVerion) and (Byte(WSA.wVersion) = MajorVersion); if not Result then begin Result := False; WSADeInitialize; end; end; end; function WSADeInitialize: Boolean; begin Result := WSACleanup = 0; end; initialization WSAInitialize(2, 2); finalization //WSADeInitialize; end. the result and that is clean WireShark view, don't you think ? also the timing is very close the ICMP ping, adjust CHECKPOINT_TIMEOUT_MS, in the above code it is 1 sec. Now to the real question because i still don't understand you are you trying to achieve, see, i will put my logic circulating in my brain, and please either correct me ( show me what i am missing ) or try be convinced with different approach. Trying to utilize TCP as ping somehow, is the point is to keep the connection alive then this will not help at all you need to 1) Use the same TCP connection you are trying to keep alive, meaning adding specific protocol Ping/Pong between you Client/Server (explained earlier), or you don't need to keep a connection alive you need to check server availability on specific port, then fine, you need to 2) A simple Connect and like (1) or, connect and then disconnect like the samples above, but in this case you don't need to send anything or wait to receive, so sending zero length data is like calling for undefined behavior or unknown consequences, like as i mentioned firewalls interactions or in this case if PERM_SACK is always there and signaling the peer (server) is it OK to selectively send ACK, then server after connect and ACK the connection it might hold on ACK after that zero length data packet, because it is within its right, keep it as much as 300ms may be, while answering your packet with another zero packet hence your client received an answer but didn't receive ACK for the send, this will cause confusion. 3) you don't want to just detect listening port ( aka open port and port scan style), you want to check the server logic part is answering requests then simple connect and disconnect is not suitable and you need to 4) Connect and send something not zero length to avoid (2) then we returned to (1) or (2) again because of (3) This loop that is bugging me. Anyway the code in this post is working fine and it is non blocking and will detect running server on specific TCP port, if you want to send and receive then the change is minimal: Repeat the select loop twice, the first to check readiness for write, the same loop above, then perform send, then another loop but for read instead of write, you need FDR just like FDW without FDW, you can use the same variable, after that you perform recv then close, do not call shutdown, and to be perfect then another loop after recv to check for read same as the first loop, and that it is. Hope that helps.

Thank you for pointing this. Yup, you are right there as i can't remember trying this on blocking connect and it seems Windows still doesn't support TCP_USER_TIMEOUT even it was RFCed since 2009 https://datatracker.ietf.org/doc/html/rfc5482 Thank you again. SACK can be disabled per socket, that i am sure of, and you can test it, but from what i can see PERM_SACK is always globally available either disabled or enabled, PERM_SACK does allow the peer to use and utilize SACK.