Why does the attached file load so slow?

[Wallenstein61]

Hello,

Thank you for this great piece of software. I use it quite often on a LaserSaur in our FabLab.

However last time I had a hard time with an SVG document prepared in InkScape.
On my testinstallation on my Notebook (DriveboardApp version 18.07) it took about 15 minutes to load. On the LaserSaur processor loading didn't finish in 40 minutes.

I was able to reproduce this problem with a simple document with 40 small 4x4mm squares. (See attached svg-file (due to upload restrictions named as .txt-File). It takes nearly one minute to load on my notebook.

AppTest1.txt

The structure of the svg-file seems quite simple. So why does it take so long to load? And what can I do to simplify it, to speed up loading.

Best regards

Wallenstein

[martinxyz]

Yeah I fixed that one in 2015.

• Fix: martinxyz/LasaurApp@a349ce2
• Historical PR (old LasaurApp repo): hanger when importing certain SVGs stefanix/LasaurApp#55

I have just tested with your AppTest1 file, and was able to reproduce the bug with driveboardapp. The patched file (svg_tag_reader.py) still exists mostly unmodified, and the bugfix still works.

I'm not going to open another PR here, because I have already two open with zero feedback.

We have made a couple of other small fixes for our fablab, for each of them there is a PR open either here or in the old LasaurApp repository, in case anyone wants to apply them to driveboardapp. We're using my pulseraster fork, which you can find here: https://github.com/martinxyz/LasaurApp (this repo is free of fablab-specific hacks, but still a bit involved to install).

(It is still based on the old GUI and uses a different firmware implementation for rastering. IMO the new GUI here in driveboardapp is a bit better, but my rastering implementation is also a bit better IMO, so tough choice. Maybe one day I'll integrate the new GUI, or rewrite it or something.)

[Wallenstein61]

Hello,

I think, have found the culprit:

InkScape sneaked in an ry="0" into the rect-Tag defininition. (The rx="0" is missing anyway)
Although not wrong, it leads the driveboardapp into a complex resolution of apparently rounded corners.

If I remove every ry="0" by hand, the file loads at lighning speed.

So the simple resolution is, to edit the input file .

Not being an intricate python expert, I would think, a programmatic resolution is:

Line 125 in svg_tag_reader.py should read

if (rx is None and ry is None) or rx=='0' or ry=='0' : # no rounded corners
instead of just
if rx is None and ry is None: # no rounded corners

[martinxyz]

Good to see you found the source of the problem. IMO the tolerance calculation is the better place to fix it because there could be other shapes that trigger the same problem. If you implement your solution, write == 0 instead of == '0'.