I'll close this for now, if there is interest we can refer back

the new canvas features should have floating feature labels

Just as a data point, rendering a ~7MB region of grape vs peach synteny with the genes track loaded slows down stuff pretty significantly with SVG

would be nice to be able to be zippy even at this scale, as sometimes large scale synteny patterns need that type of scale. the gene track doesn't have to be loaded for this example to work but it could be useful to call out various genes by color

probably labels will be rendered client side
they will use an overlay canvas sort of similar to mouse overs

possible enhancements

add separate negative and positive strand genes (e.g. request from selewis, seen on some browsers like higlass, etc)
avoid too much overlapping text (our current "collapsed" mode has lots of overlapping text)
allow text labels in compact mode

proof of concept canvas feature renderer https://github.com/GMOD/jbrowse-components/tree/add_canvas_feature_renderer

uses glyph style code adapted from jb1
includes floating feature labels
uses the rendering (client side react component) to render floating labels using a postDraw method
the postDraw method can then also be called for use on making labels in a svg export

example export

some notes on revisiting the canvas rendering concept:

here are the main reasons that SVG slows down

main reasons

0. many DOM elements on page
1. many react elements (this is quite separate from DOM, html can handle lots of DOM nodes but lots of react nodes is slow)
2. many react elements in conjunction with mobx-react observer wrappers on all of them
3. many readConfObjects per element (config system access - mobx state machinery being slow)
4. many readConfObjects per element (config system access - jexl calls being slow)
5. the round trip of main thread to worker and back is slow
6. sort of orthogonal but changing any renderProps results in full re-renders instead of reactively updating only what is needed

i have not precisely measured but i think 1, 2, 4 are sort of the main experiences of typical slowdown in the app

i think canvas can solve 0,1 and 2, it would remove all the observers and dom nodes

for 4. there are two paths 1) reducing need for calling out to jexl by 'detecting default settings' and not calling a callback if it is default. this is done in pileup renderer, looking for special color values like hard magenta (e.g. #f0f) and others. further work might find ways to improve inherent performance of jexl, or swap out jexl for something else

for 5. the hypothesis that the webworker was causing slowness was not necessarily true, can see branch mainthread_revamp for example. browsing human GFF is quite slow on it, even though no webworker rendering is involved. the mainthread rendering does potentially have the ability to resolve 6. because the main thread can be much more like a component-level (observer-type) reactive re-render rather than doing a full webworker re-render. however, it doesn't strict have to be svg for this to gain benefits

2mbp region

https://jbrowse.org/code/jb2/main/?session=share-5GYGe1vYTY&password=yQ19P (main branch, not crashing but laggy)
https://jbrowse.org/code/jb2/mainthread_revamp/?session=share-5GYGe1vYTY&password=yQ19P (experiment in no serversiderenderedblock usage, but continuing with svg, has layout glitches, this was related to 5.)
https://jbrowse.org/code/jb2/add_canvas_feature_renderer/?session=share-5GYGe1vYTY&password=yQ19P (experiment in canvas rendering, still uses webworker, much faster rendering)