search

yWorks / svg2pdf.js

A javascript-only SVG to PDF conversion utility that runs in the browser. Brought to you by yWorks - the diagramming experts
MIT License
654 stars 101 forks source link

Chrome vs Edge Performance #86

Closed scottctr closed 5 years ago

scottctr commented 5 years ago

Am I possibly doing something wrong or does it usually take exponentially longer to call svg2pdf in Edge than Chrome with similar SVG? As an example, one of my SVG elements takes 36ms on Chrome and a very similar SVG takes 5423ms on Edge. Note that the SVG is slightly different in each browser because my source, SvgExport, produces slightly different SVG in each browser.

As a first step, I'm just wondering if this is a known issue. If not a known issue, I'll dig further to better understand the differences.

yGuy commented 5 years ago

Sorry, we are not aware of that issue. And except for corner cases we are not aware that EDGE needs a different treatment with respect to this. svg2pdf is using the HTML5 API and that should be implemented by EDGE just the same as any other browser, so if there are performance issues, the cause is likely a problem in EDGE, but you never know: We haven't done extensive performance testing, either. Edge is not really in wide use, anyway and will soon be replaced by a Chrome(ium) clone and thus hopefully show the same performance as native Chrome. Please perform a profiling run and check whether the bottleneck is in your code, svg2pdf, jspdf, some browser shim, or in the native browser API.

scottctr commented 5 years ago

Thanks. There's a perf report from a short run here. I can also provide the SVG that's produced under Edge and Chrome if it would be helpful.

yGuy commented 5 years ago

Thanks - the perf report indicates that this is not a problem of the svg export, but rather of the creation of the SVG, which happens before the actual export. This looks like it has to do with the performance of getBBox() in Edge which uses almost 80% of the time. This code is used in yFiles to calculate line wrapping in SVG texts and is probably part of your node style or edge label configuration. With the minified build I and without line numbers I cannot tell for sure. Are you using "TextRenderSupport"? If so, please try using TextMeasurePolicy.CANVAS (https://docs.yworks.com/yfileshtml/#/api/TextMeasurePolicy#TextMeasurePolicy-field-CANVAS ) instead with the "addText" method in your style implementation. Obviously this has not been chosen automatically because maybe there is some CSS styling applied to your SVG texts? Or maybe because EDGE's implementation just sucks and differs too much from the Canvas measuring method. It seems like every call to getBBox() there are several hundred of them, invalidates the complete DOM in Edge and EDGE recalculates the CSS styles for every element on the screen, every time. So another (extreme) workaround to this might actually be to temporarily clear the DOM, then run the export and then reinsert the old DOM elements. Please continue the discussion with yFiles support as this is unrelated to SVG2PDF.