# Updating Progress Label During Long Calculation in Start
**URL:** https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130
**Category:** Uncategorized
**Created:** [March 10, 2026, 7:58am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130 "2026-03-10T07:58:53Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 10, 2026, 7:58am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/1 "2026-03-10T07:58:53Z")
I have a loop and a 10-second pause for calculations in **Start**.
I run it inside **WaitForRenderAndCall**.
I also have a label to display the progress percentage. But since the **Update** event is not called, I tried to update the display using `LabelPercent.Render;`, but it didn’t work.
What is the solution for this?
Additionally, on Android this causes an **“Application Not Responding” (ANR)** warning.
---
### Author:  [@kagamma](https://forum.castle-engine.io/u/kagamma)
#### Post date: [March 10, 2026, 2:42pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/2 "2026-03-10T14:42:53Z")
We _used to_ have a way to display a loading screen while loading resources, but @michalis removed it. This thread’s discussion may interest you [Show a loading progress using external dll - #5 by michalis](https://forum.castle-engine.io/t/show-a-loading-progress-using-external-dll/1847/5)
If the calculation is not related to loading resources from disk, then you should move it to Update.
---
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 10, 2026, 2:55pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/3 "2026-03-10T14:55:11Z")
Thank you for your answer. I found that topic while searching, but using a DLL is not possible on multiple platforms.
In Windows, there is `Application.ProcessMessages` for this purpose, or the option to run the process in a separate thread. However, this is almost not possible in CGE because the UI is updated in `Update`.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [March 11, 2026, 7:05pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/4 "2026-03-11T19:05:31Z")
> [@Hamid](#):
>
> I have a loop and a 10-second pause for calculations in **Start**.
> [@Hamid](#):
>
> Additionally, on Android this causes an **“Application Not Responding” (ANR)** warning.
Executing a long-running code during loading will indeed cause ANR or similar messages. From the OS perspective, your application does not respond to the messages.
We have indeed removed old approach that [was calling `Application.ProcessMessages` periodically](https://forum.castle-engine.io/t/show-a-loading-progress-using-external-dll/1847/5) during loading. There’s nothing in CGE making it impossible, it was and is possible with our UI… but only on certain platforms, like Windows or other desktops, where we “control the event loop”. It cannot work on platforms like Nintendo Switch, web, or iOS – where this is not possible, we cannot control event loop there, we must obey the “external event loop”: something external tells us to update+redraw.
( It was also somewhat hard to maintain – as necessarily we were making redraws in half-finished state. But I would probably try to keep it, if it was cross-platform. )
Looking at others, Unity also doesn’t have anything like `Application.ProcessMessages`. Your application only reacts to events (like update, redraw).
So the ultimate solution is as shown in our [zombie\_fighter](https://github.com/castle-engine/castle-engine/tree/master/examples/user_interface/zombie_fighter). This forces you to split loading code into multiple small steps (and puts responsibility on your side to make these steps “small enough”) and allows to make redraws as the steps progress.
I know, it requires some manual work to make it really work. You cannot just drop a complicated design with scenes, and tick a checkbox “load it with a nice progress bar” 🙂 Which would be nice! But it’s just not something we can do right now. I hope to improve it on the engine side, but it’s a more long-term task which we have to figure out.
We will also have [asynchronous loading](https://castle-engine.io/roadmap#async) which solve the problem of _“making these steps small enough”_ that I mentioned above. With async loading, your application can remain responsive even when doing longer task.
---
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 12, 2026, 8:52am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/5 "2026-03-12T08:52:07Z")
> [@michalis](#):
>
> Application.ProcessMessages
Here is a clear English version of what you wrote:
I have enough knowledge about **Application.ProcessMessages** and I know it cannot be a cross-platform solution.
Splitting the code into smaller pieces does not help when we are inside a loop.
One possible approach is to execute the loading logic in **Update** , meaning that one iteration of the loop runs on each update call. This may sound simple and logical, but in practice it creates problems and additional complexity during loading.
The solution used in the **zombie\_fighter** example is not really practical and seems to be more of a cosmetic demonstration.
When I try to load using **AnonymousThread** and update the UI using **Synchronize** , there are still problems. At startup I get this error:
`Project CastleWorld_standalone.exe raised exception class EAssertionFailed with message 'Assertion failure (C:\Users\hamid\AppData\Local\Programs\Castle Game Engine\src\files\castledownload_asynchronous.inc, line 563)'`.
Also, since **Synchronize** is used and the UI update is probably delayed, the loading process becomes much slower.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [March 12, 2026, 10:22am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/6 "2026-03-12T10:22:40Z")
> [@Hamid](#):
>
> I have enough knowledge about **Application.ProcessMessages** and I know it cannot be a cross-platform solution.
Indeed it is not cross-platform, that is correct. We provide [Application.ProcessMessage](https://castle-engine.io/apidoc/html/CastleWindow.TCastleApplication.html#ProcessMessage-boolean-boolean-) on platforms where it can work – desktops (Windows, Linux, FreeBSD, macOS), and Android. On others (Nintendo Switch, web, iOS) there’s no way to provide this.
> [@Hamid](#):
>
> Splitting the code into smaller pieces does not help when we are inside a loop.
>
> One possible approach is to execute the loading logic in **Update** , meaning that one iteration of the loop runs on each update call. This may sound simple and logical, but in practice it creates problems and additional complexity during loading.
If you load inside a loop, you indeed need to reorganize the code, to not have a loop inside a routine, but to track the loop status in a view, execute one loop step, and then do `WaitForRenderAndCall`.
I agree it increases complexity to reorganize code to do this.
We simply don’t have now an easier solution, to just load an existing big design (like a viewport with multiple scenes) and show a progress bar along the way. The [asynchronous loading](https://castle-engine.io/roadmap#async) will be one piece of a puzzle.
> [@Hamid](#):
>
> When I try to load using **AnonymousThread** and update the UI using **Synchronize** , there are still problems. At startup I get this error:
I would need to see a testcase to debug what goes wrong. The exception says that `TCastleDownload` landed in a state it never should have been.
If you access the CGE code from a single thread (which it seems you do) things should work correctly. Please submit a testcase to reproduce the problem, and I’ll take a look.
---
### Author:  [@kagamma](https://forum.castle-engine.io/u/kagamma)
#### Post date: [March 12, 2026, 12:36pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/7 "2026-03-12T12:36:26Z")
In my game I pretty much do it the same way as in the demo zombie\_fighter (well since my scripting language supports coroutines, writing such load code is pretty natural and straightforward).
---
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 12, 2026, 2:39pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/8 "2026-03-12T14:39:03Z")
I moved this part out of the thread:
```auto
CapsuleCollider := TCastleCapsuleCollider.Create(FreeAtStop);
Player.AddBehavior(CapsuleCollider);
Body := TCastleRigidBody.Create(FreeAtStop);
Body.Dynamic := false;
Player.AddBehavior(Body);
Player.Collides := True;
Player.PreciseCollisions := True;
```
For now, it does not produce an error.
Maybe `Player.AddBehavior(Body);` should be inside **Synchronize**. Since it did not cause any visible change in the scene, I had not synchronized it before.
Edit :
It occasionally gives this error.
Update:
On Android, the **ANR warning** was still being displayed.
I changed **Synchronize** to **Queue**. The ANR warning is no longer shown, but the label value is not updating.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [March 13, 2026, 12:14am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/9 "2026-03-13T00:14:10Z")
> [@Hamid](#):
>
> I moved this part out of the thread:
I’m afraid I’m not clear what do you do, and what of it is in a thread, and how do you use `Synchronize`. Please submit a testcase (complete code + data) to allow us to investigate, otherwise there’s too much guessing where things can go wrong 🙂
To be clear: all the usage of CGE API must happen from the same, single thread. As documented on [Threads | Manual | Castle Game Engine](https://castle-engine.io/threads) . Our API is not thread-safe (which is similar to other game engines and Pascal libraries too 🙂 ). Don’t try executing CGE API from random threads and looking whether it will work – due to how threads work, some incorrect code may sometimes randomly work, randomly crash. The only thing that is guaranteed to work is when you execute all CGE API from one, single thread, which is the thread where your code is during `Application.OnInitialize`, views methods etc.
Engine internally may employ threads to do other things (like downloads, streaming music, and in the future the async loading of assets mentioned here). On Android there are already 2 threads, one for communication with Java. None of this should be visible to you, and it’s platform-dependent when threads are used.
To be clear, you can use threads for your own work, of course. Just make sure to synchronize all the work such that all CGE API calls are within our thread. From your post, I can see you do such synchronization, but I’m not sure how do you do it / whether it is correct 🙂 Again, a testcase showing your code would make it clear.
---
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 13, 2026, 8:37am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/10 "2026-03-13T08:37:14Z")
> [@michalis](#):
>
> To be clear, you can use threads for your own work, of course. Just make sure to synchronize all the work such that all CGE API calls are within our thread. From your post, I can see you do such synchronization, but I’m not sure how do you do it / whether it is correct 🙂 Again, a testcase showing your code would make it clear.
I will try to create a small program that simulates my application.
---
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 13, 2026, 12:29pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/11 "2026-03-13T12:29:54Z")
I created a sample program. In the sample program, the error does not occur.
It works well with **Delphi** , and the progress percentage updates correctly, but this is not the case with **FPC**.
I am trying to figure out why the example does not produce an error and what the difference is compared to the main program. (Of course, the main program is more complex and performs more tasks.)
---
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 13, 2026, 7:14pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/12 "2026-03-13T19:14:01Z")
@michalis
This example loads correctly with Delphi and does not produce any errors.
However, when it is compiled with FPC for any platform, it does not work.
\*In the main program, it occasionally encounters an error, but I cannot debug it at all, and the call stack also does not show which part of my code caused it.
I need to make the example more similar to the main program.
[CopyAnimation.zip](https://forum.castle-engine.io/uploads/short-url/fP3vZdlhxotV34jitpSVVHYNvDQ.zip) (1.2 MB)
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [March 13, 2026, 11:55pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/13 "2026-03-13T23:55:32Z")
> [@Hamid](#):
>
> This example loads correctly with Delphi and does not produce any errors.
> However, when it is compiled with FPC for any platform, it does not work.
Thank you – we had a bug in the engine that made `TThread.Synchronize` do nothing when used with `CastleWindow` (not LCL) with FPC.
Fixed now 🙂 in [this commit](https://github.com/castle-engine/castle-engine/commit/9adb57381025403ae194939f528aac7827457b10). As usual, the [engine download](https://castle-engine.io/download) will soon contain the fixed version, once the new engine passes a few automated tests. You can observe [this page](https://github.com/castle-engine/castle-engine/compare/snapshot...master), when it will no longer contain a commit titled _“Make TThread.Synchronize work in FPC applications using CastleWindow…”_ then the fix is part of download.
So this makes your example work the same with FPC and Delphi.
Update: A [subsequent commit](https://github.com/castle-engine/castle-engine/commit/d293b0dd909206d90a617e138c68da518d4d4f67) fixes FPC+Android which required one thing to be correct. So please wait until also the commit titled _“Set MainThreadID on Android…”_ is part of the downloads, to have it working flawlessly on FPC+Android too.
That said:
Your application calls CGE API from non-main thread. The application you send is already not guaranteed to work.
Please heed the warning I mentioned a few posts above and emphasized on [threads manual page](https://castle-engine.io/threads):
> [@michalis](#):
>
> To be clear: all the usage of CGE API must happen from the same, single thread. As documented on [Threads | Manual | Castle Game Engine](https://castle-engine.io/threads) . Our API is not thread-safe (which is similar to other game engines and Pascal libraries too 🙂 ). Don’t try executing CGE API from random threads and looking whether it will work – due to how threads work, some incorrect code may sometimes randomly work, randomly crash. The only thing that is guaranteed to work is when you execute all CGE API from one, single thread, which is the thread where your code is during `Application.OnInitialize`, views methods etc.
>
> Engine internally may employ threads to do other things (like downloads, streaming music, and in the future the async loading of assets mentioned here). On Android there are already 2 threads, one for communication with Java. None of this should be visible to you, and it’s platform-dependent when threads are used.
>
> To be clear, you can use threads for your own work, of course. Just make sure to synchronize all the work such that all CGE API calls are within our thread. From your post, I can see you do such synchronization, but I’m not sure how do you do it / whether it is correct 🙂 Again, a testcase showing your code would make it clear.
The application you submitted does use CGE API from non-main thread:
- you iterate over X3D graph,
- you do `Target.RootNode.AddRoute`,
- you setup `TCastleCapsuleCollider`
← you do these things in `TViewMain.DoLoad` and `CopyAnimationOnly` which are _not_ in the main thread.
I understand what you’re trying to solve (speedup animation copying by threads) but this way is really not reliable. It may work by accident (it seems it does now, at least in the simple application you submitted, but evidently your larger application has random errors). _Our API is not thread-safe (and it’s the same as LCL, VCL, or other game engines)_.
If you want to speedup animation → this can likely be done by just making that code faster, even in single thread. I see your testcase in [Sharing Animations Between Multiple Characters With the Same Skeleton - #19 by michalis](https://forum.castle-engine.io/t/sharing-animations-between-multiple-characters-with-the-same-skeleton/2094/19) – thank you, I have it on TODO to investigate and propose a speedup.
---
### Author:  [@Hamid](https://forum.castle-engine.io/u/Hamid)
#### Post date: [March 14, 2026, 7:04am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/14 "2026-03-14T07:04:18Z")
Thank you, @michalis .
Yes, I wanted to use threads to make the animation copying faster and also keep part of the loading process happening while the loading screen is shown. I thought that since nothing was being rendered on the screen, it would not cause any problems.
For now, I will wait until the updated version is released.
Thank you for your help and guidance.
---
### Author:  [@phomm](https://forum.castle-engine.io/u/phomm)
#### Post date: [March 14, 2026, 6:49pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/15 "2026-03-14T18:49:02Z")
> [@michalis](#):
>
> Update: A [subsequent commit](https://github.com/castle-engine/castle-engine/commit/d293b0dd909206d90a617e138c68da518d4d4f67) fixes FPC+Android
@michalis seems that this commit broke the resulting app on android.
bc yesterday I was running everything as usual (I’m using GHA, which relies on latest master obviously), today I observe
Exception: EThread
CheckSynchronyze was called from non-main thread
this is the text of exception I see (and typed by watching it multiple times) for a fraction of a second, after that app crashes on android
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [March 15, 2026, 5:37pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/16 "2026-03-15T17:37:25Z")
> [@phomm](#):
>
> @michalis seems that this commit broke the resulting app on android.
>
> bc yesterday I was running everything as usual (I’m using GHA, which relies on latest master obviously), today I observe
>
> Exception: EThread
>
> CheckSynchronyze was called from non-main thread
This indicates you happened to have engine version
- after this commit [Make TThread.Synchronize work in FPC applications using CastleWindow … · castle-engine/castle-engine@9adb573 · GitHub](https://github.com/castle-engine/castle-engine/commit/9adb57381025403ae194939f528aac7827457b10)
- but before this commit [Set MainThreadID on Android, to make CheckSynchronize on Android OK · castle-engine/castle-engine@d293b0d · GitHub](https://github.com/castle-engine/castle-engine/commit/d293b0dd909206d90a617e138c68da518d4d4f67)
Indeed the result will be Android application crashing like you show. I see that there was a period when our GHA build first commit, but not yet the latter (also resulting Docker contained such broken version). Everything should be good now → so just upgrade and you should see everything working 🙂
---
### Author:  [@phomm](https://forum.castle-engine.io/u/phomm)
#### Post date: [March 16, 2026, 1:12am UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/17 "2026-03-16T01:12:05Z")
Yes, Thanks! I Can confirm. without any changes from my side, rebuilt apk started to work, so it definitely was an accidental fall inbetween of different castle code changes. Sorry for “panicking” 😅
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [July 18, 2026, 11:18pm UTC](https://forum.castle-engine.io/t/updating-progress-label-during-long-calculation-in-start/2130/18 "2026-07-18T23:18:10Z")
> [@Hamid](#):
>
> Yes, I wanted to use threads to make the animation copying faster and also keep part of the loading process happening while the loading screen is shown. I thought that since nothing was being rendered on the screen, it would not cause any problems.
>
> For now, I will wait until the updated version is released.
For anyone who finds this thread: Note that I managed to speedup the animation copying 100x , on one thread, by 2 optimizations 🙂 See [this thread](https://forum.castle-engine.io/t/sharing-animations-between-multiple-characters-with-the-same-skeleton/2094/19) for details.