You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a particularly difficult issue, but if implemented properly, it should give a reasonable ability for tracks to render based on each others data. A stacked area chart looks like this. For this implementation, you can assume each track being stacked has all equal x values. The specification of the visualizations will also need some type of way for tracks to label what order they should be stacked in, and if they should ignore the stacking altogether.
In my opinion, I think the feature can be implemented similar to as follows, avoiding major refactoring and still giving isolated behavior in the code.
In webgl-drawer.js.populateBuffers, the iteration outer loop is over tracks while the inner loop is over marks. There could be an if statement in this method for features such as stacking charts where instead the outer loop is over marks, and the inner loop is over tracks (this would assume each track has the same number of points). Then using the lastMark property in the VertexCalculator the vertices could be calculated. Something similar to this (psuedocode):
populateBuffers(schemaHelper){if(regularRender){/////////// EXISTING CODEletcurrentTrack=schemaHelper.getNextTrack();letcurrentTrackShaderIndex=0;this.semanticZoomer=newSemanticZoomer(schemaHelper);while(currentTrack){// Construct calculator in track loop as calculator keeps internal state for each trackletvertexCalculator=newVertexCalculator(schemaHelper.xScale,schemaHelper.yScale,currentTrack.track// Access actual track schema);letcurrentMark=currentTrack.getNextMark();while(currentMark){// A lot of the heavy lifting occurs in the track shaders, this class is mostly boilerplate for webglthis.trackShaders[currentTrackShaderIndex].addMarkToBuffers(currentMark,vertexCalculator);currentMark=currentTrack.getNextMark();}currentTrack=schemaHelper.getNextTrack();currentTrackShaderIndex++;}this.render();/////////// END EXISTING CODE}else{// collect all tracksconstallTracks=[];constallTrackVertexBuilders=[];letcurrentTrack=schemaHelper.getNextTrack();while(currentTrack){allTracks.push(currentTrack);allTrackVertexBuilders.push(newVertexCalculator(schemaHelper.xScale,schemaHelper.yScale,currentTrack));currentTrack=schemaHelper.getNextTrack();}letnextMarks=allTracks.map((track)=>track.getNextMark());while(nextMarks[0]){for(leti=0;i<nextMarks.length;i++){// This loop is where it gets difficult as you will also need to consider the VertexShader.addMarkToBuffers method// ...this.trackShaders[currentTrackShaderIndex].addMarkToBuffers(
...,
...
);}letnextMarks=allTracks.map((track)=>track.getNextMark());}this.render();}}
One way of implementing the core loop above is by combining all of the VertexCalculators into one so they can communicate with each other (a new class like ManyVertexCalculator would probably need to be made).
The text was updated successfully, but these errors were encountered:
This is a particularly difficult issue, but if implemented properly, it should give a reasonable ability for tracks to render based on each others data. A stacked area chart looks like this. For this implementation, you can assume each track being stacked has all equal x values. The specification of the visualizations will also need some type of way for tracks to label what order they should be stacked in, and if they should ignore the stacking altogether.
In my opinion, I think the feature can be implemented similar to as follows, avoiding major refactoring and still giving isolated behavior in the code.
In
webgl-drawer.js.populateBuffers
, the iteration outer loop is over tracks while the inner loop is over marks. There could be an if statement in this method for features such as stacking charts where instead the outer loop is over marks, and the inner loop is over tracks (this would assume each track has the same number of points). Then using thelastMark
property in theVertexCalculator
the vertices could be calculated. Something similar to this (psuedocode):One way of implementing the core loop above is by combining all of the VertexCalculators into one so they can communicate with each other (a new class like
ManyVertexCalculator
would probably need to be made).The text was updated successfully, but these errors were encountered: