very slow GUI rendering of some views during debug session

[AndreaFilippi]

Problem Description

The problem consists in the GUI showing white content while loading the view. This bug is present only in debug session. The time needed to load some application views may vary from few seconds to hours, in the meanwhile the application is not completly dead, some parts are still clickable but using them may lead the application to raise some exceptions from both my code and SDK code.

This problem affects 75% of ours development PCs and only appears during debug session. AIR SDK: 50.2.3 Affected environment: Desktop application running in Windows 10/11

Steps to Reproduce

To reproduce this issue i just have to launch the application with the debugger

Known Workarounds

A known workaround that considerably reduces the wait time (by x100 times sometimes) is to reduce the application to icon and get it back, after some repetitions of this move the GUI usually appears.

Unsuccesfull tests already done:

Use more powerfull PC seems not to affect the issue behaviour versions of the SDK seems not to change the situation, we have the issue since lot of years use the advance telemetry option change frame rate and other application general paramenters, for example the rendering use of GPU etc.

Possible test to do

I am available to try to solve this issue with more info or tests, please give me more informations on how could i collect usefull infos

[ajwfrost]

Hi

The first thing I'd suggest to try to work out what's happening here, would be to have Adobe Scout running whilst you do this. This should give some indication of the activities that are going on whilst it's slow.

There are lots of potential reasons for slow performance of a flex app like this:

• do you have a debugger running, and is there any view that shows local variables or similar? as if there has been a big data fetch from a server and then the debugging is trying to also pull down the information on lots of variables, it could slow things down
• how big is the data set that it's processing? Do you see any relationship between the size of the data and the length of time it takes (if you're able to use test data sets to play around with the scale..)
• does your rendering have multiple steps or have you got custom renderers involved here? it may be that each row (even when invisible) has to go through extra steps to display the content in a table, so you could perhaps end up with delays there..
• is there any dynamic layout that may happen as the data is populated? e.g. if you add a longer string, might it expand the table width and cause the whole system to need to do a re-layout operation?

thanks

Andrew

[AndreaFilippi]

Hello ajwfrost, Thank you for the support,

In my opinion, unfortunately, none of the potential causes you’ve mentioned clearly distinguish between our test PCs. Despite the PCs being the same model, the bug does not manifest in a significant way on all computers running the same application version with the same data.

My testing with Scout revealed that the advanced telemetry option significantly influences the bug’s behavior. Without advanced telemetry enabled, the application performs considerably worse compared to when advanced telemetry is enabled. Having advanced telemetry option enabled but Adobe scout closed behave like not having the advanced telemetry enabled

Please see the attached logs, which highlight the stark contrast between the two scenarios. These tests were conducted on two different PCs using the same application version, loaded with the same data, and requesting the creation of the same GUI. Both systems are running on Windows 11, are the same PC model, used the same SDK version for compilation, same runtimes, and the debugging session was run from VSCode.

Let me know if I can collect any other relevant data to help understand this unusual behavior.