You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 23, 2018. It is now read-only.
There's anecdotal evidence that <use> tags slow things down and that nesting them is bad. For every single "pad" shape, gerber-to-svg puts the shape in <defs>, and for every "flash", it puts a <use> in the main layer (that's a lot of uses). Then, when we start combining gerber-to-svg layers together with pcb-stackup, we end up with a bunch of nested <use>s, because the layers get put into defs and then <use>d themselves.
I'd like to compare a build that just inserts the shapes directly into the main to the current version to see if things feel faster (especially with some of the more complicated boards in the pcb-stackup integration tests).
The text was updated successfully, but these errors were encountered:
There's anecdotal evidence that
<use>
tags slow things down and that nesting them is bad. For every single "pad" shape, gerber-to-svg puts the shape in<defs>
, and for every "flash", it puts a<use>
in the main layer (that's a lot of uses). Then, when we start combining gerber-to-svg layers together with pcb-stackup, we end up with a bunch of nested<use>
s, because the layers get put into defs and then<use>
d themselves.I'd like to compare a build that just inserts the shapes directly into the main to the current version to see if things feel faster (especially with some of the more complicated boards in the pcb-stackup integration tests).
The text was updated successfully, but these errors were encountered: