Have coherent zoom behaviour

[SingingMeerkat]

Zoom level is used to change the display size in pixel of nucleotides. With a size too small, too many visual elements would be generated, making the whole app slower. As for now the zoom level is too much focused on big or small sizes, and not enough on intermediate size (which would allowed about 40 columns on screen at once). This zoom scale, with the intermediate pivot could be better handled and adapted to the dataset on display.

[SingingMeerkat]

How to think the default zoom ?

Accessible zoom levels should be based on a number of visible features (as it is directly linked to a number of SVGs on screen). There is actually no need to have a wide range of available zooms within the non optimized range.

Maybe have a choice/range for coherent zoom (ie not too many features at once), and fixed x-folds zoom value for the unreasonable ones? cf all view, half view, quarter view, and then only a range of zoom values ? These pre-determined zoom values could be directly linked to canvas representations?

[SingingMeerkat]

Proposed approach:

While parsing the dataset, calculate a mean block width w We'd like a zoom level that allows us to see N features/blocks or so. Displayed blocks also depends on s, the mean empty space available between blocks.

• It could be calculated precisely while parsing but overlaps and non-sorted data might make it complicated
• It can be approximated if we assume the space is uniformly distributed between blocks (not the case but, oh well). Knowing that there are Ntot features spread on a width of LastNt nucleotides (minus the first few nucleotides since it may not start at 0nt but let's not add this now) We would have : s = (LastNt - nbOfUniqNtWhichHaveFeatureOnThem) / Ntot), with nbOfUniqNtWhichHaveFeatureOnThem being approximately Ntot x w (we do not take into account the overlaps). Hence, s = (LastNt / Ntot) - w*

One feature would therefore occupy a screen space corresponding to w + s, its actual nt size plus the trailing empty space.

To display N features, the screen should therefore display N x (w + s) nucleotides, ie. N x LastNt / Ntot nt.

THEREFORE, with a display window of WPX px of width, and appropriate approximations of uniformity and feature width, we would have: N x LastNt / Ntot = nbOfNtToDisplay ; => N x LastNt / Ntot x ntWidthInPx = WPX ; => ntWidthInPx = WPX x Ntot / (N x LastNt);

=> ntWidthInPx = (displayWidthInPx x totNumberOfFeatures) / (nbOfFeaturesToDisplay x LastNt)

[SingingMeerkat]

The question is now: What should be the available optimized number of features to see?

Let's say we have a range of optimized sizes. What would they be?

• Minimum nb of features to see: Seing not enough features would make no sense, I would say 10 features is okayish. SHOULD IT BE DEPENDANT ON THE SIZE OF THE SMALLEST FEATURE ? Eg. could we fit the tiniest feature 10 times in the display window? The tiniest feature need to be fairly visible at that minimum size so maybe it would make sense to take it into account. Could add a bit of work for which I do not have much time RN.
• Maximum nb of features to see: Depending on the max number of SVG that can be displayed with no problem, knowing that nbOfSVGs = nbOfFeatures x (nbOfGenomes + nbOfTracks) so there is no stable answer to this if we do not take into account these additional SVGs. For now I would say that 100ish features is enough. Let's try with 200 features first.
• Default nb: could be an in between value of those two. Like a mean or something: (Max + Min) / 2

[SingingMeerkat]

What to do now? I think the best would be to create a copy component of the zoom, with similar inputs / outputs and with a very basic design (let's say a slider, not an fancy svg one, with only the optimized range and no outisde value). Time to branch!

[SingingMeerkat]

I found myself somehow a bit stuck as HTML input range element need a step value (or else the step is of 1), but my ntWidthInPx values might be really small, and I do not know to what extend as it depends on the dataset.

I think I could *base the step on the minimum value size, eg step = 0.1 minimalNtWidthInPx**

[SingingMeerkat]

I have different options for how to update the nt width tresholds:

• Have a commit for every new value to set (map[chrom] = {minWidth, maxWidth}), the payload being an object with all chrom, minWidth and maxWidth present. It may be only one object, cf {chromosome:'chr01', minWidth:0.5, maxWidth:2}
• Have a commit once the map is built for all genomes, and put it to the store only when it is finished. Easier but do not keep good track of commit and additions to the map.

I am sticking with the first option for now

[SingingMeerkat]

[WHERE / WHEN to add a map object]

I DO NOT need to calculate every item of the map, the only one that interest me is the thresholds for the current chrom in view. As I only need totNumberOfFeatures and LastNt from the subdataset, I do not have to extract info directly when parsing the data. Therefore I could instead update the nt thresholds values only on a change of panchrom in the main display view. This is just linked to the subdataset from the store.

Could I add ntWidthThresholds only when requested by user?

Example:

• on change of chrom, subdataset is changed
• then the ntWithThresholds must be updated. This could be done according to two options:
  1. The panchrom hasn't been already explored, value must be calculated AND stored within the Map
  2. The panchrom has already been visited, meaning that a ntWidthThresholds already exists for it --> I just have to get it back

Basically, all of this could hapen only with a change of selectedChrom from the store.

I maybe able to achieve this through a getter My getter would return a ntWidthThresholds couple in any case. When 1 happens, I create on the fly, when 2 happens I only have to get it. Plus It would automatically do this everytime selectedChrom changes !

Food for thoughts: Should I use the actions from the store? Are they useful if this is only done within the store?

[SingingMeerkat]

The zoom behaviour is now okay and default is correctly loaded when a new chromosome is selected. However user input does not seeme to be taken into account! Therefore the zoom level stays at its default value even when another value is choosen on the range. Strange.

[SingingMeerkat]

[Update]

Default zoom value is working. However I am not able to use the range object to set another value. 2 possibilities :

• The step is way too small for the range and it cannot work properly
• There are transmission errors and the update order is not (entirely) sent

[SingingMeerkat]

It seems that there is no transmission with the v-model from the html range object.

When trying with a fake, value-fixed range it is not working either, I must be missing something. At least it does not seem to be because of my data. Let's try with an example component?

[SingingMeerkat]

[Bug identified]

I had badly written the range DOM element as 'v-model' should not have any ':' before it. This completely disrupted the behaviour and no value update was detected even on user input. Strangely enough no error message was showing up.

[Caution]

It appears that user input on range element will return a String and not a Number -> use a computed numerical value to return to the data store!

[SingingMeerkat]

Mentioned in commits 0e404e09 , a4107491 and 32101e2d

[SingingMeerkat]

Closed via commit 193e2d14