This is something I have noticed occasionally over the past year or so: I am getting a beachball if I try to delete more than ~20 exports. Sometimes, after a few minutes Glyphs comes back but not all of them are deleted. Is this a known issue?
I am currently trying to reproduce this issue and thus far deleting the instances is near instant. Is there something about your font project that might contribute to the slowdown?
Not sure. I have quite a few filters and localized family names but why would they make this operation so slow?
Also, I noticed that setting instance properties via Python, e.g.
instance.axes[index] = value
is getting extremely slow (300ms up from 1.5ms) if there are too many instances/exports in the font. This happens even after I delete most of the instances. However, after I save/close/reopen, the time used for this operation is back to normal. So, the reason of the slowness must be retained even after I removing most instances.
The complexity of the instances should not be a factor. If you have a project that you can share with me, I will have a look and investigate what causes the slowdown.
Thanks for the pointer, I will look into this. I suspect this could be about the undo stack which gets dropped once a document is closed.
Some more info:
- The original font has 77 instances.
- Selecting all instances typically gives me a beachball (which suggests that the undo stack is not the only explanation).
- There are two VF settings near the bottom of the list.
- Moving the VF settings to the top of the list fixes the beachball when selecting all instances. (oops, I am getting a beachball when trying to close the file after this).
- Unfortunately, after moving the VF settings to the top, my Python code becomes even slower.
- Removing the two VF settings makes everything fast (selecting, removing, Python access).