Implement canvas rendering

[v-ko]

• PixiJS research...no, doesn't include path intersection API, and is heavier

• Optimize rendering...done

  • Drawing cache service...done
  • Urgent rendering logic...done
  • Testing...done
    • Draw cache rect and add sanity check logging in the untested functions. It's probably the projection matrix...done
    • Test arrow disappearance - probably bad ctx management...done
    • Fix dpr rendering issues...done
      • Fix viewport projection calculation - makes no sense to keep the 0,0 real coords in the viewport center...done
        • Project to topleft in Viewport...done
        • Init vieportCenter in PVS to the element center...done
        • Fix realTopLeft argument in calls...done
    • Fix denovo updates on translate (bad cache rect I guess)...done
    • No patterns appear ever....done
    • Cache rects are variable on DPR!=1 (notes wiggle on panning)...done
      • Add DPR to the Viewport ...done
    • Don't cache on closeup...done
    • There's still rendering artefacts on some scales. Translation invariant...done , fixed by increasing the cache rect padding
    • Initial render update not happening...done
    • Remove PaperJS (and pixi), replace bezier intersection functionality...no, there's no alternative and I fixed performance issues and memory leaks...done
    • Skip redundant queued renders...done

• Note rendering

  • TextLayout remove empty lines...done

  • Fix notes with new lines...done

  • Call next render if unfinished items...done

  • Plan image rendering...done

    • Take advantage of browser cache

    • Add a lazy image loading service - notes will query it when rendering and will provide fallback container size. The service will either return the image or a placeholder depiction

      • The lazy image service keeps its state in the appState (queued downloads)
      • Well the whole service has to be a queue with cache. I.e. keep most frequently accessed in memory (that is optional actually, but preferable) and regardless if retrieved from cache or abroad - deliver each item to be "consumed" by the renderer. This may be implicitly achieved through the image access method. This means the image disappears on scaling tho.. But only if there's too many images (>cache), which is ok. Which means I don't need a strict consumption mechanism/queue, neither the implicit freeing. Just a cache, and an on-screen warning for "too many images. Will not render all".
      • Alternatively: Since I'll have a boundary on the acceptable image count (for full rendering) - I can implement that in react and not deal with the service. I only need to synchronize react rendering with the canvas rendering to avoid artefacts
      • Final? a lazy image service that queues images for download (+/- in a service worker) upon calling the access method. The service has a view-state: on each finished download a counter is incremented to trigger page rerender, a flag indicates if the queue is empty (shows a spinner otherwise?)

      Final:

      • Upon further consideration - the max note size is 1920x1920. That will be the max image preview size too, which with adequate compression means acceptable memory requirements. The server will provide images with the size of the note (on each note resize - the backend updates its cache). On the cloud/desktop backend the original file is kept (subject to size restrictions). On the PWA backend - files are resized on upload (to 1920x1920, lossy) and kept in the indexDB. On page render - the notes with images will be added as hidden elements (with a placeholder fallback) and their references will be mapped to their NVS/url in the canvas-renderer. The canvasDraw will accept not ctx, but the renderer as a parameter (and will access images by retrieving its ref via some method)
        • since we'll be keeping references (i.e. note view react state) - we can go ahead and add all notes for SEO (invisible) and call the canvasDraw in the component... NO, the two renderers (react, and my canvas-renderer) are separate concerns
          *On the PWA backend - files are resized on upload (to 1920x1920, lossy) and kept in the indexDB... NO , i don't want to deal with caring for the image life cycle
        • Write down the plan in a structured manner...done

  • Render the img tags for the media components with react

    • Will just create the elements hidden with react and query them at render time via the document API...done
    • parseMediaUrl error (mutable data mistake?)...done

  • Implement add/get/clear image element reference...no

  • Put note rendering logic in CanvasElementView components - functional (the simpler option) + leave only NoteViewState (no note-type-specific states). The mapping will be on the View level

    • Add ElementView registration...done
    • Rename the page renderer...done

  • Implement ImageView...done

    • Remove card notes?...yes

  • InternalLinkNote...done

  • Test...done

  • Implement CardView...no

  • Draw link borders when appropriate...done

• Arrow rendering...done

  • Draw arrow head...done

Acceptance criteria:

• Correct rendering for all types of notes and for arrows
• Low latency when stress testing

Story points:
13 / XL