Rafal.B

Hello everyone, I have a SCADA-style application (FMX). It contains several threads, each of which communicates with a PLC, reads data from it, and enqueues it using TThread.Queue to synchronize with the main thread. Each queue entry represents a change in some value (appearance) of a visual component. A single read may involve 300–600 data points. On the main form, I also have a TTimer that updates the current time in a TLabel every 1000ms. There are also a few buttons on the form. In D12, everything works very well. The form's responsiveness is normal (very good). Unfortunately, something has changed in D13. Visual components updated via TThread.Queue are refreshed correctly, but the time display from TTimer refreshes only every 3–15 seconds. Button response is also similarly delayed. It looks as if the handling of TThread.Queue (on the main thread side) consumes 99.9% of the main thread's time. It seems to be a problem with modifying a large number of components on the screen (at least that’s my impression), but... Let me repeat — in D12 everything worked flawlessly. I have no idea what they changed, but D13 is starting to feel like bad luck 😞 Any suggestions on where to start looking for a solution would be greatly appreciated. I know this is a very general description, but I’m unable to share the source code.

I thought I was the only one experiencing this issue. It turns out I’m not alone. The problem doesn’t seem to be trivial. Link to the topic:: Animations (FMX) are blocking the application. - RAD Studio Service - Jira Service Management This option also helps.

I didn't say it was impossible. It's just taking longer than I expected. I've already tried a method similar to what you described. It didn't work. But "the devil is in the details." I'll keep trying 🙂

Thank you. I'll try this soon. I know that. However, the situation is unique. The program must run in its "natural environment." It must be connected to a PLC. Otherwise, there's no problem 😞 I'm still trying to create a program that would represent this problem without using a PLC. So far, however, I haven't been able to get anywhere.

I reported it. However, I realize the difficulty in documenting this phenomenon. Animations (FMX) are blocking the application. - RAD Studio Service - Jira Service Management

Unfortunately, I am unable to create a separate application that exhibits the same issues. For the problems I previously described to occur, the original application must also operate in its natural environment (active TCP/IP connections with several PLCs). Any other attempt fails to produce the desired effect. I am therefore forced to stick with these SCADA applications on Delphi 12, where everything works perfectly. I know this has nothing to do directly with the computer's performance. To simplify, the issue appears as if the message queue is no longer being handled by Application.ProcessMessages. Perhaps a situation will arise that helps narrow down the search area. In the meantime, thank you all for your interest and suggestions.

I'm trying to create a program that demonstrates the problem, but unfortunately, it's not working out. This might be a serious issue. I'm considering an alternative solution — using the old animation handling method in the new D13. Is that possible? Does this make sense? Perhaps EMB could create a small Old/New Animation switch? 🙄🙂

Interesting fact. The program launched several times (4-5 times) in the IDE64 environment without any problems. Subsequent launches resulted in a known error. Nothing in the configuration had changed in the meantime. It's like magic 🙂

Maybe I'm not being clearly understood. I don't see any issue with computer overload. The same application running on D12 uses the same amount of CPU (~5%) and GPU (~30–40%) as when running on D13. Animations that are already running continue to work smoothly. However, buttons and timers placed on the main form stop working. And yet, the running animations still perform smoothly 🙂 Clicking on the screen only causes a 'beep'. I'm not using Skia. In my components, animations are configured via the object inspector, and in the code I only use ...Animation.Enable := True/False; Where exactly should I place BeginUpdate/EndUpdate? I don't quite understand 🙂 I tried this: BeginUpdate; ...Animation.Enable := True; EndUpdate; Unfortunately, it didn't help. I guess I'll have to create something similar just to have something to send to QP. Thanks all for your interest in the topic.

No, I don't use it.

Thanks. I'll try.

No, I haven't used it. Which one would you recommend? That's why I haven't reported it yet 🙂

Still general, but with more detail: The program (thread in background) receives 300–600 data items every 100ms. They are sent to a queue (I replaced TThread.Queue with TThreadedQueue to gain more control). On the main thread side, a TTimer (Interval = 50ms) retrieves data from the queue and performs preliminary filtering (unchanged data is discarded). In practice, only 0–15(20) items remain that require component updates. This mostly involves changing the Visible or Text properties, less frequently triggering color (TColorAnimation) or position (TFloatAnimation) animations. And that’s all. There’s not even a need to wrap this in BeginUpdate/EndUpdate. Is that really a lot? During testing, the program was stressed with up to 4000 data items every 100ms. There were no issues with handling that load. Everything ran smoothly and responsively. But that was done in Delphi 12. That’s why I chose to implement this project in that environment. Unfortunately, Delphi 13 flipped the table. From a quick glance, I see that they replaced the previous AniThread with a new "Display Link Service" for handling animations. That’s where I believe the root of my problems lies. I want to report this to QP, but there’s no room there for a sufficiently detailed problem description. Can I include a link to this topic as the problem description?

I realize this is a rather complex topic. I've determined that the problem is 99% related to graphics display. Running one of the animations (TFloatAnimation) that changes the X position of an element (TPatch) causes the main thread to lock (screen unresponsive). But not always. It's difficult to diagnose. First, I wanted to disable the Display Link Service, but unfortunately, there doesn't seem to be an option. I'm looking for detailed information on the changes to FMX support introduced in D13. Unfortunately, it's hard to find anything useful.

I don't see anything new either. Total items: 157

Hi everyone. In short: - I installed a clean D13 on my laptop - I installed FMX Linux - I configured all the necessary data for the Linux platform (Tools->Options->Deployment->etc.) - I created a new, empty project (Target Platforms = Linux) - I compiled and ran it without any problems Then: I installed the "RAD Studio 13 September Patch" And the problems started. Attempting to compile the program (as above) results in errors: [Fatal Error DCC] Project39.dpr(6): F2613 Unit "FMX.ScrollBox" not found. Project39.dpr(6): The object "FMX.ScrollBox" is used by the object "FMX.ScrollBox.Style" Project39.dpr(6): The object "FMX.ScrollBox.Style" is used by the object "FMX.Text.LinesLayout" Project39.dpr(6): The object "FMX.Text.LinesLayout" is used by the object "FMX.Text.SpellingManager" Project39.dpr(6): The object "FMX.Text.SpellingManager" is used by the object "FMX.Text.TextEditor" Project39.dpr(6): The object "FMX.Text.TextEditor" is used by the object "FMX.Text.InteractiveSelectors" Project39.dpr(6): The object "FMX.Text.InteractiveSelectors" is used by "FMX.Edit.Style.New" Project39.dpr(6): Entity "FMX.Edit.Style.New" is used by "FMX.Edit" Project39.dpr(6): Entity "FMX.Edit" is used by "FMX.Dialogs.Default" Project39.dpr(6): Entity "FMX.Dialogs.Default" is used by "FMX.Dialogs.Linux" Project39.dpr(6): Entity "FMX.Dialogs.Linux" is used by "FMX.Platform.Linux" Project39.dpr(6): Entity "FMX.Platform.Linux" is used by "FMX.Platform" Project39.dpr(6): Entity "FMX.Platform" is used by "FMX.DialogService.Sync" Project39.dpr(6): The "FMX.DialogService.Sync" entity is used by "FMX.Dialogs" Project39.dpr(6): The "FMX.Dialogs" entity is used by "FMX.Platform" After some struggle, I found a solution: Add: "$(BDS)\source\fmx" to "Tools->Options->Library->Library Path" or "Project->Options->Compiling->Delphi Compilers->Search Path->..." I was going to report this to QP, but... I tried the same thing on a newly created virtual machine (Proxmox) and everything worked perfectly there. I don't understand this and I don't know what the problem is.

Thank you, it works. However, the question remains why this sometimes happens.

Unfortunately, b48 on x86 and x64 causes identical errors as the previous version.

I confirm. Indeed, selecting the option to close the welcome page causes an error (which I described first) when closing D13.

When I open a project with the original IDE plugin "Open Recent," there are no problems (errors) when closing D13. Some time passed, and... everything started working fine. I didn't do anything except open and close D13 several times. I don't understand this situation. It's just a hocus pocus. 🙂 I'll see what happens tomorrow 🙄

I ran another test. I uninstalled D13 and cleared all folders and registries. I reinstalled D13. Then gksoftPlugin370. (I didn't install MMX!) I created MyProject (FMX), saved it, and closed it. Then I opened it using: gksoftPlugin370 -> Recently used -> Projects -> MyProject Then I closed D13. This time it behaved a bit differently; I immediately got the error: "Strange situation. I don't really understand what's causing the error, it's definitely not MMX."

There's no problem with D12. I don't know about D11, I don't have it 🙂

Hello. A new problem has appeared in D13. Following the list below, it's reproducible: 1. Install D13 2. Install MMX 3. Install gksoftPlugin370 4. Load project from this plugin (important) 5. Close D13 At this point, the operation takes quite a while, and finally, I get an error (shown below). If I don't install MMX or (after installation) uninstall it, everything works fine. Installing MMX and gksoftPlugin370 together has a problem. Considering that MMX is very necessary in D13, I can't get rid of it. It would be nice to have gksoftPlugin370 as well 🙂

Thanks.

It's already 13 🙂