MewPurPur
commented
1 month ago My current ideas are:
Multiline drawing can be optimized by using the built-in method in Godot 4.3- PathData should become something like 2x faster when the performance of
matchin GDScript gets addressed by the Godot contributor gang. Other than that, we may still be able to get minor gains from optimizing the logic. The biggest thing would be interoping with C++, which appears to be a bit of an undocumented hassle. - Inspector rebuilding could maybe be optimized a little more too, by drawing things before they are really added.
- Lazy loading would be useful in the inspector, if we can get it to work.
- It might be smart to not draw path commands until they are on screen.
- It might be possible to draw path commands (which are just a bunch of the same stylebox) more efficiently.
- Polylines can maybe be optimized by grouping them up (they are currently one per command, but for example, a lot of consecutive lines can be made into a single polyline)
- Multithreading; but for now, the only idea for multithreading I have is for the graphic - which can be split into smaller strips. It doesn't seem like there are good gains to be made there.
This report uses splash.svg, an SVG made only from paths, with one of the paths being very long. While this isn't exhaustive, it's pretty representative in my opinion of the things that need to be acknowledged.
Changing the text gave my laptop a 200ms lag spike. Let's go over some of what I consider interesting. Note that some of the below might overlap:
Would be great if we get to identify more things.