Lazarus
Programming => Widgetset => GTK => Topic started 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)
-
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.
-
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.
-
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.
-
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.
-
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...
-
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.
-
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...)
-
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
-
Pls a hint, will fpTimer unit help me (if I replace TTimer to this fpTimer)?
-
The default driver uses threads, it should work.
-
New seeing of this: I see that replacement of TTimer to TfpTimer dont help (sometimes caret still stops).
So seems TTimer is okay.
-
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.
-
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