Scale to long sequences

[ihh]

e.g. genomes

[ihh]

Possible strategies/experiments:

• help the layout engine out by specifying each column's x-position in its CSS class (make the rowsDiv object position:relative and then the columns are all position:fixed)
• switch to a Canvas-based rendering strategy
• use a just-in-time strategy where parts of the alignment that are way offscreen are shunted out of the DOM, and replaced with big empty fixed-width divs (to preserve the scrollbar state)
• for genomes, even holding this many spans in memory might be excessive, so we could create the spans just-in-time as well

[cmdcolin]

Just in time rendering is good. I tried using a react-window based grid like this which just-in-time renders things which works ok, but if we add zooming out that adds a ton of cells and then it will slow down. https://react-window.now.sh/#/examples/grid/fixed-size

See here, containing 15x30kb virus genome MSA

https://cmdcolin.github.io/msa-view-react-window/

It ends up being too slow if you zoom that grid out

That suggests to me that we might need is like what jbrowse does with block-based style rendering

[cmdcolin]

Xref #10 and #14

[ihh]

I agree just-in-time DOM manipulation seems like the obvious if it weren't for zoom. Zoom would be nice, I think it's more essential for genomes than proteins, but now that I've started thinking about it... I want it ;) I also added an issue for genome-to-protein alignments (#23)

@rbuels suggested WebGL. This page is interesting https://css-tricks.com/techniques-for-rendering-text-with-webgl/

It's a fairly simple problem in WebGL terms - you have a sprite sheet (of colored letters) and you want to blit a bunch of those sprites onto a canvas, fast enough for animation to look slick.

I think fast animations are pretty important for this app because it implicitly conveys the sense that you can move around evolutionary and sequence space with great ease.

I just committed a change which replaces my image-scaling hacks with CSS transforms (another @rbuels suggestion, in fact quite obvious with hindsight, I'm a bit embarrassed I forgot that transforms worked on fonts).

[ihh]

It might be worth trying a quick WebGL experiment to see how fast it is with LOTS of sprites.

[cmdcolin]

I have seen webgl demos that are pretty impressive. I kind of like to hold onto traditional browser tech, which includes canvas, but webgl could be a interesting frontier. This webgl genome browser demo was pretty cool and renders a lot of dots...manhatten plot... https://twitter.com/KariLavikka/status/1239910074539261953?s=20 https://genomespy.app/examples/GWAS/OCAC-HGSOC/

I think that when zoomed out it is probably just going to be colored blocks rather than colored letters also, and maybe even have that when zoomed in? reading colored letters is kind of hard sometimes

[ihh]

Colored blocks make sense when zoomed out but protein biologists will demand the letters. There are different amino acid color schemes that people typically use - I just picked one of the most colorful - there's no single universally accepted coloring (and in any case many amino acids are colored the same).

Interesting point about traditional browser tech, do you mean that WebGL is not universally supported? Or just that it doesn't play as well with other things? It looks pretty widely supported here?

[ihh]

btw that pv viewer is using WebGL, so we are kind of committed that anyway (at least if structures are being displayed)

[cmdcolin]

I just feel like there are benefits to using traditional HTML layout for example, once you use webgl you have to invent a system of layout positioning especially if you want multiple "components" in your webgl visualization

[ihh]

True although in this case we already control the layout pretty tightly (so the tree matches the alignment)

I definitely benefited from using HTML layout when starting this, and I guess I could imagine letting the HTML layout drive things a bit more (e.g. if there are text divs hanging under each alignment row, containing longer paragraphs or something like that)

I am not sure I see any practical difference between rendering on a canvas using a 2D rendering context, and rendering on a canvas using WebGL

[ihh]

*apart from speed

[cmdcolin]

Probably not much difference between canvas and webgl besides ease of using the API. I'd be fine with webgl though

[ihh]

I think it makes sense to push the HTML layout approach a bit more with just-in-time, with one eye on WebGL for zooming.

I just tried an experiment where I explicitly positioned the spans with left and it was significantly slower than using the default browser layout. Which, at the moment, is just

• each row gets its own DIV
• the rows are stacked on top of each other using flex-direction: column
• the individual characters are laid out horizontally in a row, using flex-direction: row

I suspect it might be more efficient to use CSS grid layout. I think that's what was in your react example @cmdcolin?

Anyway I am going to try some experiments with just-in-time rendering next.

[cmdcolin]

In the demo I posted, it uses react-window which uses absolutely positioned elements. It is kind of similar to jbrowse in some ways, jbrowse creates absolutely positioned "blocks" for its blockbased track types

We could possibly improve upon it in some ways, but I think that it will end up having issues especially if we have zoom out functionality, that will introduce too many little span elements

[cmdcolin]

That will happen just due to sheer number of DOM elements and will not really be able to be optimized well. At that point when number of DOM elements becomes too large, drawing with canvas or something makes sense. This is probably a factor in msa-js using canvas for example

[cmdcolin]

I know that flies in the face of my previously mentioned "try to use native HTML" layouts for example :) but number of DOM elements is a factor, and unless we toggle between native HTML and canvas (html5 canvas or webgl) when zoomed out then native HTML may not play well

[ihh]

This is an interesting (interactive) benchmark: https://www.construct.net/en/blogs/construct-official-blog-1/internet-explorer-10-fast-762

Basically just draws as many squares as it can onto a Canvas (using both html5 and WebGL) until the framerate drops to 30fps. You get around 8k with HTML5 and 30k with WebGL.

[cmdcolin]

I might not have proper hardware acceleration on my computer so I actually get the same for html5 canvas and webgl canvas (~10k)

[ihh]

interesting!