Canvas: Sluggish performance issue when multiple nodes enter/exit the view

[Kolyan]

Steps to reproduce

• create new vault
• create canvas
• add 100 single line text cards
• pan the canvas

Did you follow the troubleshooting guide? Yes

Expected result

No significant freezes

Actual result

Every time some elements are appear/dissapear from the viewport there are noticable freezes. But when all elements are present on the viewport, panning makes no freezes.

Video example

Obsidian canvas performance issue

Environment

SYSTEM INFO:
Obsidian version: v1.4.14
Installer version: v1.1.9
Operating system: Windows 10 Home 10.0.19045
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on
AMD Ryzen 5 4600U

Also checked on another machine, with fresh Obsidian install, with the same result:
AMD Ryzen 9 5900x + GeForce RTX 3060 (200 text cards are required to get the same performanse issue)

---

Additional information

I’m guessing it is because some internal optimisation takes place when the element dissapears from the viewport, but instead of helping the performance it worsens it

Yes, I know, 100 notes is a big amout, but depending on the machine that kind of problem may appear on 40+ notes, which is a reasonable amount. I expect the performance to be comparable to the graph view, where you can have 1000+ notes with the title shown, without any performance issues.

Thank you for developing Obsidian!

[demeneer]

A hacky solution is increasing the size of the wrapper canvas element using a .css snippet so that nodes aren’t removed/inserted at the canvas edges when moving around. Adding a css transition on the canvas element also reduces ‘choppiness’. You can even further enhance rendering performance by setting svg shape-rendering to optimizeSpeed.

.view-content:has(> .canvas-wrapper) {
  overflow: hidden;
}

.canvas-wrapper {
  width: 1000%;
  height: 1000%;

  left: -450%;
  top: -450%;

  .canvas {

    transition: transform 60ms ease;
    will-change: transform, scale, translate;

    > svg * {
      shape-rendering: optimizeSpeed;
    }
  }

  .canvas-controls {
    right: calc(45% + var(--size-4-2));
    top: calc(45% + var(--size-4-2));
  }

  .canvas-card-menu {
    bottom: calc(45% + var(--size-4-2));
  }
}

This snippet makes canvas navigation silky smooth on my not so beefy laptop.

[armadillo]

It works !
have you found additional hacks to make it even more smoother ??

[demeneer]

Another one I tried but haven’t fully formalised, is taking a static snapshot (e.g a high resolution png) of the canvas that is larger than what is displayed every time user events have timed out. This snapshot is then put in place of the canvas when zooming/panning and hidden once again after navigation.

This obviously has resolution issues at extreme zoom levels, but does not require expensive SVG redraws, as it only recalculates node positions on the first and last frame while using the static snapshot in between.

A less hacky solution would be coming up with a way to draw SVG/HTML nodes inside an actual HTML Canvas element, after which drawing passes can be calculated on the GPU. However, this will complicate styling the nodes via CSS and general accessibility.

Another way would be pre-caching the content of nodes, or off-loading this to a WebWorker so that reading notes from disk won’t block the main render loop.

[WhiteNoise]

Thanks. Renamed the thread for clarity.

[demeneer]

In my case however, choppiness also occurs for much smaller sized canvases, which is why I wrote this snippet. When enabled, my machine has no rendering issues durimg navigation, so a different lazy-loading strategy seems warranted.

[demeneer]

Maybe React.window could offer benefits?

[hxxsx]

Hello demenner, thank you very much for your method. However, on my computer, whether I enable or disable the plugin, there is a serious flickering bug, which actually makes the performance worse

2024 08 23 12 54 58

2024 08 23 12 56 15

SYSTEM INFO:
Obsidian version: v1.6.7
Installer version: v1.6.7
Operating system: Windows 10 Enterprise 10.0.19045
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: dark
Community theme: Blue Topaz v2023111501
Snippets enabled: 9
Restricted mode: off
Plugins installed: 61
Plugins enabled: 24
1: Advanced URI v1.42.0
2: Edit History v0.1.3
3: Git v2.25.0
4: Paste URL into selection v1.7.0
5: Recent Files v1.4.1
6: Remember cursor position v1.0.9
7: Settings Search v1.3.10
8: Version History Diff v2.2.1
9: Chronology v1.1.11
10: Excalidraw v2.3.0
11: BRAT v1.0.1
12: Canvas Block Reference v0.0.4
13: Style Settings v1.0.8
14: Extract url content v0.12.1
15: Auto Link Title v1.5.4
16: Latex Suite v1.7.4
17: Easy Typing v5.5.0
18: Remotely Save v0.5.18
19: List Callouts v1.2.7
20: Custom Attachment Location v4.7.0
21: Canvas2Document v1.2.0
22: Update time on edit v2.4.0
23: Search In Canvas v1.1.1
24: Multi Properties v1.1.2

RECOMMENDATIONS:
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

[demeneer]

I think that maybe due to a combination of rendering large files and intensive plugin processing, you’re experiencing this?

[hxxsx]

I think the file content might be too large? I tested it in a sandbox environment (without any plugins or other CSS snippets), but the issue still persists.

[rmoff]

I have a Canvas of ~140 nodes and similar number of edges.

When I drag or zoom it gets laggy, particularly once zoomed in so that text is rendered.

The lag is more pronounced when the window is full-size on my larger monitor (3440 x 1440). It’s still present when full size on the laptop’s monitor (1728 x 1117)

Reproduced in the Sandbox vault.

FWIW I found this similar post.

Steps to reproduce

1. Start sandbox vault
2. Open it in finder
3. Add test.canvas
4. Open test.canvas in Obsidian
5. Zoom out so that the text is not rendered. Now zoom in once.
6. Observe the lag when :
   • zooming in and out
   • Dragging the canvas around

Did you follow the troubleshooting guide? [Y]

Expected result

Smooth experience

Actual result

Laggy experience

Environment

System info:

  Obsidian Version 1.4.16 (Installer 1.4.13)
  macOS Sonoma Version 14.1.1
  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro18,2
  Model Number:	Z14X0007XB/A
  Chip:	Apple M1 Max
  Total Number of Cores:	10 (8 performance and 2 efficiency)
  Memory:	64 GB

SYSTEM INFO:
	Obsidian version: v1.4.16
	Installer version: v1.4.13
	Operating system: Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000 23.1.0
	Login status: not logged in
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none

[woofy31]

It happens on Windows, too, so I bet this is either a limitation of Electron, the engine behind Obsidian (if Obsidian were to be written in a native programming language, things would probably run butter-smooth), or the graphics framework that Obsidian uses might be far from perfect.

[demeneer]

Using the following snippet increases performance immensely:

Performance issue with Canvas when panning out of region with a large number of nodes

A hacky solution is increasing the size of the wrapper canvas element using a .css snippet so that nodes aren’t removed/inserted at the canvas edges when moving around. Adding a css transition on the canvas element also reduces ‘choppiness’. You can even further enhance rendering performance by setting svg shape-rendering to optimizeSpeed. .view-content:has(> .canvas-wrapper) { overflow: hidden; } .canvas-wrapper { width: 1000%; height: 1000%; left: -450%; top: -450%; .canvas { …

[WhiteNoise]

This bug will be fixed in v1.7.2. No ETAs.

[Sam12]

I found that if a markdown (MD) file is referenced in a canvas, editing the MD file also causes lag. Is this a bug? You can try opening the canvas and then opening the MD file referenced in the canvas in another window. If a markdown file is referenced by cards or other markdown files in the canvas, editing the referenced or displayed markdown file will cause their response speed to be as slow as editing directly in the canvas. So, I think the logic and processing of canvas editing and markdown editing should be different, right?

Hope the official team can optimize Canvas performance, with a summary of multiple test contents attached

Two Issues: Editing delay under Canvas (for cards and referenced markdown files) Scrolling delay under Canvas I have tested the 13900K+3090, 7950x+4090, and 7950x3d+4090, and there is a serious issue with Canvas performance. No configuration can smoothly run a Canvas card with 26,000 characters of content Feature Requests: Please add multi-core support for Canvas. Currently, it seems only two threads are working. Align Canvas editing with markdown editing. From my personal tests, they cle…