Lazarus

Programming => Widgetset => GTK => Topic started by: Alextp on January 20, 2019, 08:48:46 am

Title: TTimer is not safe
Post by: Alextp on January 20, 2019, 08:48:46 am
I've seen few things in CudaText, it leads me to conclusion that TTimer
is broken on Linux gtk2 x64 (Ubuntu 18.04). fpc 3.0.4.

- caret stops blinking (sometimes, after Alt+Tab)
- syntax parsing cannot end (sometimes, works by timer too)
- inactive buttons, still hilite after cursor moved out of window (have timer workaround which works most of the time)
Title: Re: TTimer is not safe
Post by: Thaddy on January 20, 2019, 10:56:02 am
We had a similar issue at my old job. After TThread.Queue was introduced we changed our design to a threaded model where each threads loop iteration was closed with a sleep(0) which means relinquish time slice.  This gave an unexpected performance gain of over ~20% . The issue is not GTK specific: it can also happen on Windows under heavy load.
You need to test with a slower Intel type windows machine to verify this (some Celeron notebooks and AMD E series notebooks were used to reproduce our issue by our testers).
It may well be that a similar approach will also work for CudaText.
Title: Re: TTimer is not safe
Post by: Alextp on January 20, 2019, 11:48:12 am
hmm, I cannot get the idea: timer was broken after TThread change or timer was fixed after TThread change?
how can I fix/workaround it?
I'm using fpc 3.0.4.
Title: Re: TTimer is not safe
Post by: Thaddy on January 20, 2019, 01:35:10 pm
The idea is to *not* use a TTimer but queue any pending updates and sleep(0) after every loop iteration.
A timer is really not the best solution for CudoText. A Sleep(0) will execute one of the pending updates in the main thread, which is a better model.
Title: Re: TTimer is not safe
Post by: 440bx on January 20, 2019, 01:42:01 pm
how can I fix/workaround it?
A workaround depends on knowing why it is not working.  However... 

You could try creating your own thread to post Timer messages to the application's message pump.  If the problem persists (which it very well might) then you could have the thread itself perform the actions needed instead of posting a message, for instance, call the procedure/function/method that would have been executed if timer messages were being processed correctly.

HTH.
Title: Re: TTimer is not safe
Post by: Thaddy on January 20, 2019, 01:55:10 pm
You could try creating your own thread to post Timer messages to the application's message pump.
No, that has the same limitation. A TTimer is limited and not precise enough to rely on with many tasks pending, because the rest of the code would possibly block.
But the rest what you wrote is basically what you do when you use the queue feature of a thread. That is a correct conclusion by you.
Since the feature is not very well documented yet - not even for Delphi !- , I will see if I can come up with a readable example.

My point is that CudaText does not need a timer to schedule those tasks. It just needs to schedule.....with a low enough resolution...
Title: Re: TTimer is not safe
Post by: 440bx on January 20, 2019, 02:09:00 pm
No, that has the same limitation.
Not quite.  One of the reasons I did occasionally implement it is because, in Windows, timer messages are very low priority and, depending on the application, that can get in the way of timely updates.  Using a thread is more responsive than using timer messages or callbacks based on them.

The downside is, it's more work than relying on Windows (in my case) to simply generate the message(s) or executing the callbacks.

I cannot say if it would work for what @Alextp wants to do since I am not familiar with CudaText.  It's up to him to evaluate the idea/method and determine if it would solve the problem he is experiencing.


Title: Re: TTimer is not safe
Post by: Alextp on January 20, 2019, 02:19:19 pm
Quote
My point is that CudaText does not need a timer to schedule those tasks. It just needs to schedule.....
I don't know how to replace timer with your method (don't know how to write threads + app has many timers: for caret, for button cursor watch...)
Title: Re: TTimer is not safe
Post by: engkin on January 20, 2019, 02:22:42 pm
Probably there is a problem in your code. A good explanation and an easy workaround are in this SO thread:
https://stackoverflow.com/questions/11957954/ttimer-not-firing
Title: Re: TTimer is not safe
Post by: Alextp on January 20, 2019, 02:38:30 pm
Pls a hint, will fpTimer unit help me (if I replace TTimer to this fpTimer)?
Title: Re: TTimer is not safe
Post by: engkin on January 20, 2019, 03:05:32 pm
The default driver uses threads, it should work.
Title: Re: TTimer is not safe
Post by: Alextp on January 30, 2019, 11:17:53 am
New seeing of this: I see that replacement of TTimer to TfpTimer dont help (sometimes caret still stops).
So seems TTimer is okay.
Title: Re: TTimer is not safe
Post by: marcov on January 30, 2019, 02:40:27 pm
Empty the handler method of your ttimer but leave it in, do the problems go away? If so, your timer routine simply is too heavy and eats up to much time.
Title: Re: TTimer is not safe
Post by: Alextp on April 24, 2019, 09:49:13 pm
Sorry for noise. Now i think TTimer is safe - i just see some issue in my app and now I think the reason is not timer.
https://github.com/Alexey-T/CudaText/issues/1733