Speed-up view.FindSidebar

[beru]

This PR attemps to speed-up FIND sidebar by replacing SVG icons with font letters.

I used https://icomoon.io/app/ to create netron.woff font file. I also used https://iconly.io/tools/svg-convert-stroke-to-fill to convert strokes to fills in SVG files.

To check speed difference, efficientdet-d3.onnx file can be used.

Rasterized shapes of icon letters are somewhat different from original SVG icons. So some adjustments would be needed...

Before/After

Before	After

[lutzroeder]

Can you provide more context. How much is the improvement? Is maintaining a font the only option? If there are adjustments needed, which are these and why are they not included in the pull request?

[beru]

Can you provide more context. How much is the improvement?

I recorded a screen to show the difference.

speed comparison

efficientdet-d3.onnx file is used.

Before (037c36d)	After (2ee4d83)

Is maintaining a font the only option?

List Virtualization would be an effective solution for slow FIND sidebar. But implementing by myself takes time and efforts.

Netron's current implementation uses so called External symbol sprite for the icons, it seems like there're other faster methods but I guess using a web font is the quickest.

If there are adjustments needed, which are these and why are they not included in the pull request?

Compared to the original SVG icons, Connections icon and Weights icon based on the icon font look thin. So I need to adjust its shapes using SVG editor software such as Inkscape. It's because of haste they aren't included in this PR.

[beru]

I've updated the font. Now the icons look almost the same. Not pixel identical though.

Before/After

Before (7b993c6)	After (2a34ef2)

[beru]

Calling Document: createElement() method to create a lot of list items is time-consuming. So I've updated the code to use Node: cloneNode() method.

speed comparison

efficientdet-d3.onnx file is used.

Before (037c36d)	After (a97b4f3)

I've also updated the font again. The icons look almost pixel identical now.

Before/After

Before (7b993c6)	After (a97b4f3)

[beru]

Here beru@56118a1 is another version that doesn't use a web font. We can see that the other changes are still beneficial.

speed comparison

efficientdet-d3.onnx file is used.

Before (037c36d)	After (56118a1)

[beru]

While testing with efficientdet-d3.onnx file, I've noticed that repeatedly opening and closing the FIND Sidebar makes the app screen broken. The problem reproduces with current main branch (7.8.8 Desktop App, Windows 10 22H2 and Ubuntu 24.04.1 LTS). This might be a bug or a limitation in Chromium. I don't see the same problem when the icons are drawn with the web font (this PR's code).(edited: the problem happens eventually.) Also, the problem doesn't occur with Firefox browser.

a screen recording

Maybe I should open a new ticket to report this bug. Opened #1358

[beru]

There's a different idea. Instead of creating an svg element per li element, creating a single vertically long svg element that contains icons and overlaying it to the ol element would be more efficient.

[lutzroeder]

Here beru@56118a1 is another version that doesn't use a web font. We can see that the other changes are still beneficial.

Let's switch to this approach if it has some of the same benefits (new pull request or replace this one). Custom font files are harder to maintain and given this issue hasn't been reported widely seem an expensive trade-off. If there are other options we should try them as well.

The main improvement in this change is from cloning nodes? If so could this be accomplished by remembering the first node created which would avoid the need for createDocumentFragment?

There's a different idea. Instead of creating an svg element per li element, creating a single vertically long svg element that contains icons and overlaying it to the ol element would be more efficient.

Creating and reusing existing SVG elements as items come into view or become invisible might be another idea? Which part of using individual SVG icons makes this slow? Is this happening on all machines and browsers or specific configurations?

[beru]

Let's switch to this approach if it has some of the same benefits (new pull request or replace this one).

I'll create a new pull request.

Custom font files are much harder to maintain and given this issue hasn't been reported widely seems an expensive trade-off. If there are other options we should try them as well.

I understand so I'll try different approaches.

The main improvement in this change is from cloning nodes?

I believe so. If I remember correctly, the use of createDocumentFragment didn't make much difference. I'll examine it.

If so could this be accomplished by remembering the first node created which would avoid the need for createDocumentFragment?

I'm not really sure about that. My understanding is that when DOM nodes are added to on-screen DOM tree, it can cause frequent layout calculations. By using the DocumentFragment, that can be avoided/reduced.

Creating and reusing existing SVG elements as items come into view or become invisible might be another idea?

I think that's what's called List Virtualization technique.

https://tghosh.hashnode.dev/rendering-large-lists-in-vanilla-js-list-virtualization

Which part of using individual SVG icons makes this slow?

I've checked that use of <svg> icons in a numerous number of <li> list items is the main culprit.

42024 list item nodes

efficientdet-d3.onnx file used.

Is this happening on all machines and browsers or specific configurations?

This happenes on all Chromium-based browsers/applications.