Forum Bugs

window.getComputedStyle performance

Build: Prince 11.3
Environment: Windows 10 (10.0.15063 Build 15063)


I've encountered a case where I'm seeing >1000ms times to calculate the fontsize when calling window.getComputedStyle(elem).fontSize. Most files only take ~2ms to ~6ms, so this is a large outlier.

Chrome, Firefox and Edge all take significantly less time to perform the calculation on this file, so I was hoping someone could take a look under the hood and see if there's something going on. We have a batch of files taking over 3.5 hours to convert most content takes minutes at most.

Steps To Reproduce (example files and .bat to run attached below):

  • Unzip the archive
  • Make sure you're currently within the extracted folder and run convert.bat. Output is set to "verbose" and logging is included so you should see the number of times PrinceXML is reloading the CSS/fonts
  • Open /text/input_js_embeded.xhtml in a browser of your choice, open developer tools and check the console output. You can then compare the times taken to perform each action.

Although I doubt it's the cause of this performance issue, it looks like Prince is reloading the CSS files everytime the DOM reflows. This could possibly be cached since it's not possible for external files to change?
  1. prince_test.zip3.6 MB
    Sample files and command to repro
The files themselves might already be cached, but Prince is doing a significant amount of potentially unnecessary work recomputing the style environment for the document, eg. in case any style elements have been added or modified since getComputedStyle was last called. This could be cached and streamlined considerably, although it will take a bit of work on our part.
Could I register my interest in this being looked at? I've made as many optimisations as I think I'm able to, we're not able to improve performance any further without Prince being updated.