AllocHwnd + TTimer = lag?

[aehimself 396]

Hello all,

 

I have a progress indicator on a panel which is visible until a thread is running. On here is a timer which is updating the status of the thread every second (elapsed time, some data from inside the thread, etc.). The .OnTerminate event of said thread has a custom message sent to the panel so I can do some final touches plus freeing the thread object up:

 PostMessage(Self.Handle, UM_WORKERENDED, 0, 0);

Procedure TProgressPanel.UMWorkerEnded(Var Msg: TMessage);
Begin
 _worker.WaitFor;
 FreeAndNil(_worker);
End;

All was working fine until a recent refactoring, when I changed the panel to a TObject for modularity reasons (now said panel can display different content, so I had to move the progress indicator to it's own).

Since a TObject has no handle I created a dummy window with AllocHwnd and sending my message on this dummy handle. Everything works like clockwork, but I realized that the status update timer became laggy. Sometimes it refreshes too quickly (from second 1 to 2 in ~750 msec) and later on delaying more than 1 second (from second 2 to second 3 in 1,25 sec). Elapsed time is measured with a TStopWatch so I doubt the issue is with the measurement.

 

I am aware that the TTimer works via Window Messages - is it possible that adding a dummy window with AllocHwnd (which is picking up ALL window messages, not just the one specified) causes the code to simply be overwhelmed, not processing WM_TIMER in time?

 

[Lars Fosdal 1792]

I've had issues with having multiple allocated hWnds and messaging.

Ended up with a single allocated hWnd and a custom message broker/router for my user messages.

 

[Fr0sT.Brutal 900]

1 hour ago, aehimself said:

is it possible that adding a dummy window with AllocHwnd (which is picking up ALL window messages, not just the one specified) causes the code to simply be overwhelmed, not processing WM_TIMER in time?

If a window is dummy, it won't receive many messages. You can check it by logging every entrance to windowproc.

I hope you alloc a window in the context of main thread? Window handles belong to thread that created them.

Anyway do you also have timer inside worker thread? Or it is living in main thread and queries thread's status to display?

Edited July 14, 2021 by Fr0sT.Brutal

[David Heffernan 2345]

2 hours ago, aehimself said:

which is picking up ALL window messages, not just the one specified

It's not going to be sent many messages. 

 

Can you reproduce the behaviour in a cut down program?

[Dalija Prasnikar 1396]

Processing messages for whole application happens in one place. WM_TIMER is low priority message and it will be dispatched only after all higher priority messages are dispatched. The fact that WM_TIMER messages are not being processed fast enough means that you application is either flooded with messages or is doing to much work in main thread, including code called with TThread.Synchronize and TThread.Queue.

 

Changing from TPanel to TObject with allocated handle should not have any impact on processing speed. 

 

Also using WM_TIMER for progress is usually poor approach, it is better that you send status from the thread when you have some significant change to show. 

 

Additionally, if you are sending messages from OnTerminate event then you don't need to wait on thread (also freeing the thread will also wait).

 

It is hard to say more without having reproducible example.

[aehimself 396]

Thank you @Dalija Prasnikar, I learned some new things about window messages! Unfortunately though, none of the above applied to my case.

 

After the comment of @Lars Fosdal I got rid of the TTimer and used the same dummy window to catch the now manually fired SetTimer messages too. I also included a counter which increases each time a window message is received (whether processed or not) to see how swarmed application is. With a timer of 1 second, 70 seconds of runtime I got 72 messages. 1 is UM_WORKERENDED, I count the extra 1 as an acceptable discrepancy due to the timer's accuracy (or something unprocessed).

So no, it was not the window messages.

 

The solution is so painfully trivial I'm almost afraid to share...

 

In the TComponent my timer was set to 750 msec to update the elapsed time on the UI. As I'm using TStopWatch, I manually converted the .ElapsedMilliSeconds to some readable format... using dividing and substracting.

 

First time the timer fired at 0,75 seconds, UI was updated with the rounded 0 seconds.

Second time the timer fired at 1,5 seconds, UI was updated with the rounded 1 seconds.

Third time the timer fired at 2,25 seconds, UI was updated with the rounded 2 seconds.

Fourth time the timer fired at 3 seconds, UI was updated with the rounded 3 seconds.

Fourth time the timer fired at 3,75 seconds, UI was updated with the rounded 3 seconds.

 

Even if the timer component is spot on it can be seen that every 3 seconds, for 2 seconds the elapsed time does "not update"... thus the feeling of variable speed.

 

After upping the sampling to 1000 msec instead of 750 and some small tweaks to the conversion everything seems to be working fine.

 

Why it was working on the TPanel...? Because originally I forgot to change the default 1000 msec interval to 750...

 

What a nice way to waste a day by debugging something, which is working as it should 🙂

Edited July 14, 2021 by aehimself

[Lars Fosdal 1792]

That is waaay to familiar.  As a developer, you never run out of chances to own yourself.

[Remy Lebeau 1393]

5 hours ago, aehimself said:

I am aware that the TTimer works via Window Messages

Yes, and not only that, but it allocates its own window internally to handle those messages.  So it doesn't really matter if you create your own window or not, each window will handle only its own messages, but everything is going through a single message queue.

5 hours ago, aehimself said:

is it possible that adding a dummy window with AllocHwnd (which is picking up ALL window messages, not just the one specified) causes the code to simply be overwhelmed, not processing WM_TIMER in time?

Creating your own window will not cause such issues for TTimer.  And your own window will not pick up any messages that are not specifically targeting that window.  It is, however, possible that your own messages can cause delays in TTimer, because WM_TIMER is a low-priority synthesized message, so it will not be generated until the message queue is idle, unless you force it.  So don't overwhelm the message queue unnecessarily, regardless of which windows are involved.