Repainting dashboard windows before exporting to png when switching workspaces

Question

question

Przemyslaw Pasich asked Apr 22, '24 Przemyslaw Pasich commented Apr 26, '24

Repainting dashboard windows before exporting to png when switching workspaces

Context: I want have a workspace set up with a number of dashboard windows each of which will be exported to a .png. Then switch into that workspace and run that export using one user command. The desired result:

Problem: after I switch to another workspace using

treenode screenshots_workspace = Model.find("Tools/Workspaces/screenshots");
applicationcommand("openworkspace", screenshots_workspace, 1);

the dashboard windows don't manage to paint the contents of their graphs before the consequent exports to .pngs take place:

treenode view_node = views().find("active/DockingGUI");
string filePath = modeldir() + "test.png";
viewtofile(view_node, filePath);

and that results in exporting screenshots with empty graphs:

I tried the following ways of forcing the paint instruction to execute before the exports:

repaintall();
repaintview(view_node);
msg("", "Desperate attempt at giving the paint instruction more time to execute.");

However, none of them worked.

Any ideas how to resolve this problem? I am attaching a model that recreates this issue.

force repaint before screenshotting.fsm

Software Version:

FlexSim 24.1.0

flexscript dashboards workspace export to png

test2.png (13.7 KiB)

test.png (9.6 KiB)

force-repaint-before-screenshotting.fsm (29.5 KiB)

Answer 1 · 2024-04-22T15:01:37Z

Jordan Johnson answered Apr 22, '24 Przemyslaw Pasich commented Apr 26, '24

Repainting doesn't work because charts are managed in a separate process. The trick is to have the script wait for a bit before exporting:

applicationcommand("openworkspace", screenshots_workspace, 1);

// Schedule the rest of the script to run 0.5 seconds later
await Delay.realTime(0.5);
// Once the delay finishes, the script continues here

// export the screenshot
viewtofile(...);

Usually, an await handles waiting for the model clock. But in this case, await waits for the real clock to move.

https://docs.flexsim.com/en/24.1/Reference/CodingInFlexSim/WritingLogic/WritingLogic.html#coroutines

· 3

Przemyslaw Pasich commented · Apr 23 at 09:18 AM

Hi Jordan, thanks for the reply - with your suggestion it works as intended on the sample model. One thing I'm curious about: would that approach be prone to a "racing" problem? If I had a dashboard with numerous elements and my PC takes longer than the hard-coded 0.5s painting them, would that result in the export activating prematurely giving improperly rendered pngs?

0 ·

Jason Lightfoot ♦ Przemyslaw Pasich commented · Apr 26 at 09:45 AM

Doesn't this question answer itself? If the time to render is longer than 0.5 seconds then you will not get a completely rendered view at that time.

0 ·

Przemyslaw Pasich Jason Lightfoot ♦ commented · Apr 26 at 11:19 AM

I saw that interjecting with the msg() halted both the export statement and the rendering of the graphs - so I figured FlexSim cannot do graph rendering as a parallel, independent process. And so I hoped that introducing a realtime delay makes FlexSim go "since the user command is instructing me to wait anyway, let me grab the next thing on to-do list (rendering all the graphs) and complete that before I come back to the user command and see whether those 0.5s passed" - with that approach, the graphs would render before exporting no matter the delay length.

One way or another, thank you for answering my questions! I appreciate it. My problem was solved.

0 ·

question