Best practices for providing track height

[rmhubley]

I have run into an issue while designing a track that uses autoHeight. I have implemented a packing function that, in addition to the features, depends on having the bpPerPixel and graphics context (for calculating text measurements). I assumed that I would simply call my packing routine from implementations of getFeatures() or computeTrackHeight(), however neither of these function signatures provide the graphic context, and computeTrackHeight() doesn't provide bpPerPixel. I was forced to use the standard computeTrackHeight (MAX(row)+1), and place my packing call in draw(). The side-effect being, in the initial load of the browser computeTrackHeight() is called before draw() and the track height is calculated from un-initialized row assignments.

I wonder if there is preferred design for tracks that need to perform a height calculation based on scale and text measurements?

[jrobinso]

Sorry I don't have a solution for you. Redesigning packing for this case would be a major refactor.

[rmhubley]

No worries, my workaround is working well enough for the moment. Perhaps this is something that can be labeled for discussion when/if you decide to refactor.

[rmhubley]

I wonder if this might be a solution to the issue I brought up before. The current state-flow of a generic track is:

constructor(config, browser)
init(config)
getFeatures(chr, bpStart, bpEnd, bpPerPixel)
computePixelHeight(features)
draw(options)

It seems that several tracks use getFeatures() to initiate feature packing prior to obtaining the packed height in the computePixelHeight() call. This makes sense if the packed max-row-depth is simply a function of bpPerPixel and doesn't require the graphics context for text width estimates.

What is confusing to me is what happens when the track configuration is changed via a menu selection, that could have an impact on the packing of the features. For example, what if a track supports filtering of features that meet some sort of score criteria. The controller currently doesn't call getFeatures() again, but rather simply calls computePixelHeight() and then draw().
It would appear to me that in this case packing is a concern of computePixelHeight() and not getFeatures().

Ok...on to my suggestion. Would it be possible to augment the current signature for computePixelHeight(features) to be computePixelHeight( features, bpPerPixel, context )? For current track implementations the additional parameters would be ignored, however new tracks would be able to utilize the additional information to calculate robust height values.

[jrobinso]

I've added "bpPerPixel" to the function call.

The canvas context (if that is what you are referring to) is not available when computePixelHeight() is called. In fact, the height returned from computePixelHeight() is used to construct the canvas. There's nothing preventing your "computePixelHeight()" implementation from creating a throw-away canvas to compute the text metrics, however.