[Bug] very slow rendering

[khimaros]

Description

very slow rendering with ~6k line file (50k words)

not much formatting, just a journal essentially

Environment

• OS: Debian Forky
• Ferrite version: 0.2.7
• Installation method: pre-built binary

Steps to Reproduce

1. enable rendered view
2. open a large file

Expected Behavior

scrolling should be responsive

Actual Behavior

it is incredibly slow on my Framework 13 laptop

[OlaProeis]

Hi @khimaros! the specific file size (~6k lines, 50k words) and hardware context (Framework 13) are very helpful.

Root Cause Analysis

You're experiencing a fundamental architecture limitation in the rendered/preview mode, distinct from the raw editor. Here's what's happening:

The Rendered View Pipeline (Current)

When "rendered view" is enabled, every frame Ferrite must:

1. Parse the entire markdown via Comrak (O(N) where N = total document size)
2. Build egui UI widgets for every element (paragraphs, lists, headings)
3. Layout all content — egui calculates sizes for the entire document, not just visible portion
4. Render — even off-screen content contributes to layout calculations

With a 50k word journal file, this creates significant per-frame overhead that scales with document size. On a 60Hz display, that's 60 full document parses/layouts per second.

What We Fixed in v0.2.7 vs. What Remains

Fixed in v0.2.7 (Raw Editor):
The custom FerriteEditor (raw mode) uses virtual scrolling — it only parses, highlights, and renders the ~50 visible lines. This was heavily optimized in v0.2.7 and should handle large files more smoothly now.

Remaining (Rendered View):
The WYSIWYG/rendered view (markdown/editor.rs) currently builds the entire document structure each frame. It lacks the viewport-based culling that makes the raw editor fast.

Why This Is Harder Than It Sounds

Unlike the raw editor (uniform line-based content), rendered markdown has:

• Nested structures (lists within blockquotes within callouts)
• Variable-height elements (tables, mermaid diagrams, images)
• Bidirectional dependencies (footnotes, backlinks, wikilinks)
• egui integration — we use egui's built-in widgets which expect complete layout information

Simple viewport culling breaks down when:

• A single paragraph spans multiple screens (with word wrap)
• Tables have hundreds of rows
• Mermaid diagrams are taller than the viewport
• Cross-references need global document knowledge

Roadmap & Timeline

Immediate Workaround (Available Now)

Use Raw mode or Split mode with Raw focus for large journal files:

• Raw mode: Ctrl+Shift+R (or View → Raw)
• Split mode: Ctrl+Shift+S (edit in raw, preview occasionally)

The raw editor handles your file size smoothly — it was specifically optimized for this in v0.2.7.

Short-Term (v0.3.x — Late 2026)

Viewport-Based Rendered View Optimization

• Implement "windowed" markdown rendering similar to FerriteEditor
• Parse only visible content + small margin
• Cache parsed AST chunks (like our CSV byte-offset row index)
• Lazy widget construction for off-screen content

This is tracked under our Memory-Mapped I/O & Large Document initiative (see Roadmap v0.4.0).

Long-Term (v0.4.0+)

Full Virtual Document Architecture

• Incremental markdown parsing (only changed regions)
• Persistent AST with change tracking
• Background thread document processing
• Support for GB-scale files (memory-mapped I/O)

Why We're Prioritizing Other Features First

You might wonder: why not fix this immediately?

1. The raw editor workaround exists — power users editing large files can use raw mode
2. Most markdown files are <1000 lines — the current approach works well for typical docs
3. Architecture risk — viewport-based markdown requires significant changes to our Comrak integration and egui widget pipeline
4. Resource allocation — v0.2.8 is committed to LSP integration and text shaping (HarfRust), which benefit all users; v0.3.0 focuses on RTL/BiDi and Mermaid crate extraction

Data Gathering

To help us prioritize and test future fixes, could you share:

1. Does Raw mode perform acceptably? (Ctrl+Shift+R)
2. File characteristics:
   • Approximate file size in MB?
   • Heavy use of any specific elements? (tables, code blocks, images, mermaid diagrams)
3. Performance metrics:
   • Does scrolling stutter continuously, or only when new content enters view?
   • Is typing laggy in rendered mode, or just scrolling?

Related Work

• [Feature] CSV Support #19 — Memory-mapped I/O for GB-scale files (planned v0.4.0)
• v0.2.7 Large File Optimizations — Raw editor fixes (completed)
• CSV Lazy Parsing — Similar viewport-based approach used for large CSV files (1M+ rows)

Thank you for reporting this — large document performance is on our radar, and reports like yours help us prioritize the viewport-based rendered view rewrite.

In the meantime, Raw mode (Ctrl+Shift+R) should give you a smooth editing experience for your journal files.

[hansinator]

This slow rendering makes it unusable for me.

[khimaros]

I regularly edit this file in obsidian with no problems

[OlaProeis]

@khimaros Based on your feedback (and @hansinator's), Im pulling rendered view performance optimization forward to v0.2.8. Specifically: AST caching (stop re-parsing 60x/sec when nothing changed) and basic viewport culling (only render visible blocks). These won't reach full virtual-document level, but should make your 6k-line journal significantly more responsive in rendered mode.