[HtmlDialog SU2024] Serious lag at load of the dialog

[Fredosixx]

I noticed a strange behavior in SU2024. In short, the delay between the call to HtmlDialog#show and the first message received by Javascript (onDOMContentLoaded) can vary from a factor 1 to 10.

I observe this issue:

• for SU2024, Windows and Mac
• Never in SU2023 (Windows and Mac)
• The variation of the delay seems to be random (see video attached): same dialog with same data called several times. Normal delay is around 0.12s, but can randomly become 1.2s, which is viusally perceivable.
• Not all dialogs are concerned.
• On Mac, the lag is less frequent, but I can observe it.

https://github.com/SketchUp/api-issue-tracker/assets/57754157/1557094a-c099-4c0d-9f01-cf9e72784c13

Unless I am wrong, there is no Ruby script excuted between HtmlDialog#show and the event (DOMContentLoaded). So, this is internal processing by the CEF and Sketchup. From the video, we can also notice that the dialog appears immediately with correct rendering, and 1 second later, we see the trace of the DomContentLoaded event in the Ruby console. This means that the lag occurs AFTER the processing of the HTML and Javascript of the page.

I have spend some time to try reproducing the problem with a simple example. But no luck so far.

The best would thus to use the main dialog of my plugin ThruPaint, where the lag is noticeable when it happens (note that all the titlebar decoration and resizing happens anyway AFTER DomContentLoaded, so after the lag.

Can the Extensiility team profile what happens in the Sketchup and CEF code between the call to #show and the event DOMContentLoaded?

Again, this is something new, that happens in SU2024 RC0 (I am not sure it was present in Beta 2.

[sketchup[bot]]

Logged as: SKEXT-4142

[timlanier]

Hi Fredo. We're having trouble reproducing this. In your video, which extension are you showing? I can't find the green rocket icon. I thought it might be Fredo Tools but that doesn't seem to have the same dialog. Which one is it?

We tried adding timing for ThruPaint but we're not seeing the problem. Our dev did point out that you're passing us html in this plugin which means we need to write to disk, so was there something else running on your machine at the time like a virus scan that could have caused these delays?

[MSP-Greg]

I doubt this is the cause, but I've noticed that all the blocks defined by UI::Command#set_validation_proc are running when Ruby code isn't executing, which could occur when the code is waiting for the onDOMContentLoaded callback.

The screen grabs show quite a few toolbar items (UI::Command objects).

Could the set_validation_proc blocks affect things?

[Fredosixx]

The point is that, on the same computer, same plugin environment and same code.

1. This does NOT happen with SU2023
2. This does happen in SU2024, but interestingly, the lag seems to be random as shown in the video.

If it was a matter of writing HTML to disk, then it would show in both SU2023 and SU2024 and probably be constant (instead of random). Same for the validation_proc (which by the way are not running permanently on Mac).

Since this happens both on Windows and Mac, it may be related to the new CEF rather than Qt. However, I recall this came in RC0 and I did not notice it in the Beta series (although I mainly skipped Beta 0 and Beta 1).

At least, if you are not able to observe the lag, this means that many users won't get it too, which is good news.

The fact that it is random is really puzzling. It reminds me my problem with the non-display of Errors in the Ruby console, which is also random, even when executed in a row.

[MSP-Greg]

@Fredosixx

I'm not suggesting that you're not seeing this, I was just wondering if the validation_proc's could be blocking the calls between Ruby and the dialogs.

One way to check is to disable all the extensions in SU 2024 and see if you still observe the intermittent delay.

are not running permanently on Mac

I don;t recall if I tested it on macOS. I'll see if I can find the code I used...

[Fredosixx]

The lag happens between dialog.show and the first event received by Javascript (DOMContentCreated). During this time, there is no Ruby code of the extension invoked. Everything running is within the CEF and Sketchup code.

With simple dialogs, I cannot reproduce the issue so far. It might be related to the HTML I pass to the HtmlDialog, but then, why is the lag random?

For Mac, validation_proc runs on some occasion, but you have to use UI.refresh_toolbars to force a refresh of the toolbars state.

Note: If you have ThruPaint in your environment, can you try to see if you observe the lag. After all, I might be the only one observing it in the galaxy.... (noting however that Dave Edward also noticed it on Mac).

[timlanier]

Fredo, I completely agree that the write-to-disk delay theory doesn't explain the 2023/2024 difference. I do wonder if it could be something environmental on your machine since we're not able to reproduce it. Could you try this on another machine?

Also - we'd like to try to repro this with the same extension you were using in the video. What extension is that?

[Fredosixx]

The extension shown in the video is private to me (this is my interface to automate the generation of encrypted RBZ on EWH).

You can try FredoTools::ColorByAltitude, as shown in the attached video illustrating the lag in SU2024 (vs never any lag in SU2023):

https://github.com/SketchUp/api-issue-tracker/assets/57754157/68b4a3c5-9852-47fa-9bfc-091ff31d8837

You can also run the following code from the Ruby console (press Enter after each dialog box display to chain the next one)

for i in 0..20 ; G6.messagebox 'This is a message' ; end

This is the simplest dialog I have (just display a modal dialog box message and a button). I do observe the lag, although less frequently (when the lag happens, you have a brief momemnt of 1s where the dialog is white).

[timlanier]

Thanks for the extra context and examples. I can see the lagginess in your video but we're not experiencing the same thing on our machines (recent Core i7's with 32GB of RAM). Your ColorByAltitude dialog pops up for me quickly and completely every time.

We also did your timing test with ThruPaint:

I got thrupaint as he mentioned and added a stopwatch to time between Dialog::Show() and when the loading callback is fired in our ruby code (LoadingStateChanged where we call the ruby callback). I also edited the html he is loading to log when dom is done loading and I consistently see that it takes about a quarter second. We consistently show that dom is loaded before firing the loaded callback.

I think I'll see if I can find a less powerful machine and test the theory that the lag is caused by the machine not being able to keep up for some reason.

[Fredosixx]

Tim,

Many thanks for looking into this issue.

I think there must be something else, because of the randomness of the lag. When the lag occurs, it is adding about 1 second between show and DomContentCreated on top of the regular 0.2s.

I have a core i7 too. And again, I never observe the lag in SU2023, on the exact same machine and plugin environment. So something came with SU2024, and its probably on the side of the CEF.

If this just me and no other users of my plugin see that, that a less severe problem.

[Fredosixx]

It looks like the issue was solved in SU2024 Build 553.

I keep the thread open until I can confirm.

[timlanier]

Fredo, this sounds encouraging. Have you confirmed this is fixed? If so I'll close this issue.

[Fredosixx]

On Windows, it never occured again. So, it seems to be fixed.

On Mac, I did not notice it, although I don't really test heavily on Mac thse days.

So, we can consider it closed with SU2024 Build 554.

However, when closing it, it would be good to know what was the origin of the problem so that it does not happen again (exceptif the fix is accidental as the side effect of another change).