Wt

With Wt 4.12.0 (vs. 4.10.0), there is a regression in performance for rendering some DOM elements, e.g. AREA, on update. This regression is particularly noticeable with Firefox (version 141.0). Also, the Firefox console logs errors for updates of AREA elements, such as those used by WCartesianChart tooltips.

To observe the issue with Wt 4.12.0, one can enable tooltips in ChartsExample.C with the attached patch in:

0001-Enable-tooltips-in-ChartsExample.patch

Then, browse to the example with Firefox with the browser console open and update the "Scatter Plot (time series)" chart by enabling the additional Series (FTSE100, HNGKNGI, JAPDOWA, SNGALLS, and SPCOMP). The response time should get progressively worse as each series is added and there should be numerous messages on the log of the form:

The “coords” attribute of the <area shape="rect"> tag is not in the “left,top,right,bottom” format.

To make it easier to time the delay in different scenarios and browsers, I've attached a crude patch that replaces the wait indicator with log messages estimating the browser wait time:

0002-Log-estimate-of-browser-wait-time-in-ChartsExample.patch

Based on git bisect, the issue appears to have been introduced with commit 4.10.2-46-gdf59d8b1 (first included with Wt 4.10.4). Testing with this commit reverted, the issue does not occur.

The console error component of the regression actually appears to be due to an older issue where DOM elements that get updated through Javascript (rather than inner HTML) are added to the DOM before they have their attributes added. So in the above Firefox error (The "coords" attribute...), the message is misleading -- the actual problem is that an AREA element is added to the DOM without any attributes (including coords and shape).

Attached is a commit that modifies the order in which DOM elements are added so that the attributes are added to the element prior to adding the element to the DOM. In some limited testing, it eliminates the Firefox console errors and reduces the performance regression significantly. See:

0003-Update-DOM-element-attributes-before-adding-to-DOM.patch

For context, here are some timings for enabling the final SPCOMP after enabling FTSE100, HNGKNGI, JAPDOWA, and SNGALLS) in the "Scatter Plot (time series)" on an older development system with Firefox 141.0 and browser console closed with Wt 4.12.0 and first two patches (0001-Enable-tooltips-in-ChartsExample.patch, 0002-Log-estimate-of-browser-wait-time-in-ChartsExample.patch):

15,038 ms Baseline 4.12.0
4,109 ms Baseline 4.12.0 with patch 0003-Update-DOM-element-attributes-before-adding-to-DOM.patch
1,570 ms Baseline 4.12.0 with 4.10.2-46-gdf59d8b1 reverted

So, there is still a large performance penalty vs. reverting commit 4.10.2-46-gdf59d8b1. I'm not sure if there is any way to make that commit more selective in its effect.