WebMagic on CI latest on bare metal hardware runs very slow (especially text rendering)

[dnesbitt142]

Hi all,

I have been testing the latest CI Latest NC build on my P3 Celeron Box running FreeDOS 1.4 and JEMM. WebMagick is the current build is noticeably slower now on the machine, especially text rendering, where it sometimes takes a second or two to load in each word (especially on toastytech.com). Here is a link to a video of the browser loading the GEOS Infobase

Kind regards,

Dan

[jirkakunze]

Is rendering in GeoWrite also very slow?

Can you please check with Perf whether there are any abnormalities visible during page loading (memory and processor load)?

Have you tried deleting the TTF-CACHE.000 file in Ensemble/privdata (please back up the file first)?

[dnesbitt142]

Rendering in GeoWrite acceptable (CI-Latest does seem a little sluggish overall compared to earlier builds from Aug/Sept). Deleting TTF-CACHE.000 does not seem to make a difference.

WebMagick does not like Pref being open it seems, either the system will run low of 640K, or will hang after a while.

[mgroeber9110]

I think I can reproduce this, even with GeoWrite. If I turn off images (for speed) and then got to http://www.tagesschau.de, I see glyphs displaying slowly each time they are rendered for the first time, and then fast when I scroll back.

The I do the following do make it happen in GeoWrite:

• Select All -> Copy -> Paste the page's text into an empty document
• Save the document
• Shut down Ensemble as usual
• Restart Ensemble
• Open the file in GeoWrite and start scrolling
• Slow rendering can be observed in the same way as previously seen in WebMagick

Before this experiment, I had deleted the TTF Cache file (but I saw the same issue even with this).

So, it feels to me like the TTF cache is not persisted across sessions (or perhaps not written at all, and I am just seeing redering from the normal glyph cache?).

[mgroeber9110]

Correction: deleting the TTF cache file failed for me when I tried this the first time, so that first test was not conclusive.

Looking at the operations of TrueType_Cache_UpdateFontBlock it seems that the size at least some of fonts (e.g. nsansbo.ttf) does not match the size that is stored in the prebuilt cache file that we include, and so the cache entry is ignored.

I think it would make sense to do two things:

1. Recreate Tools/build/product/bbxensem/Images/TTF_CACH.000
2. Extend the cache mechanism so that TrueType_Cache_ReadHeader validates the font size and magic for a given file name and, in case of a mismatch for an existing entry with the same name, discards that entry, assuming that there cannot be two font files in the system with identical names and different contents. Perhaps CheckHeader would be a better name for the new function?

This would allow us to live with stale pre-built caches for longer, as the user would at least still benefit from updates to their local cache.

[jirkakunze]

@mgroeber9110 thanks for the analysis. I'll take a look at it.