-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Rewrite WebGL code in regl #949
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
More I get into gl-vis code more I realize that it is reasonable in terms of size/solutions. |
I agree text rendering with WebGL has diverse compromises depending on the method, tesselation ( In the 3D case, the applicability of 2D canvas for text is more of a challenge in that some of the text needs to be presented properly as part of the 3D space, i.e. possibly occluded by things in the 3D scene. Perhaps even for such cases, it's possible to do canvas text by analyzing whether a feature of interest (to which the text label belongs) is visible or not. Such analysis is possible because this is how picking works already. So even for 3D, if it's satisfactory to switch text labels on/off depending on the visibility of their anchors, text can be done with 2D canvas. Similar to this consideration, there should ideally be more shared code between SVG and WebGL parts, for example, using the same exact contour model for both. Also, we can reuse some of the SVG elements for the accelerated substrates; e.g. why not render 2D plot axes, tooltips (as now), legends etc. in SVG, as there's no performance benefit to rendering in WebGL just for a few elements. Such unification alone can lead to other significant code size decrease and closer or perfect feature parity. WebGL layers can be used where truly needed, i.e. where the expected element count is at least in the thousands (e.g. lines, point markers, perhaps error bars - though I'd be more in favor of resampling resolutions because thousands of error bars are undecipherable anyway). Also I'd expect some code collapse resulting from better sharing across things that are currently in different |
P.S. |
P.P.S. having said that, I agree that |
Funny, that is exactly what I did in webgl plot-grid after consideration of text-cache size and complexity of rendering lines in webgl, especially h/v lies, which are the worst case for antialiasing. |
Nice! Also, good call on the gridlines, they come and go anyway when you zoom/pan, and you never need a lot of them at any given moment, otherwise they lose their ergonomics. I.e. the simplest thing is to draw them with Canvas dynamically according to the ever current visible domain. Re text, my recent experiment showed that 1000 words can be individually animated at high speed (60FPS in Chrome / Safari, 40 in FF). We'll probably never need 1000 words in one frame, esp. at 60FPS, even a dense full-page chart would have maybe a few hundred short texts (mostly, numbers), otherwise there's undesirable overlap (or reversing it, one would cull text labels to avoid overlap before trying to render too much text). For reference I took the 1000 words from https://hipsum.co/ :-) (To clarify, I literally meant superimposing a Canvas layer, not even transferring it to a WebGL texture) |
For the notice https://github.com/dfcreative/regl-scatter2d |
|
Should we consider trellised, SPLOM and small multiple usages early in the design? The panels may or may not have identical projections or shared dimensions. IOW if it's designed with multi-panel use, it'll still work fine with a single panel, but the opposite is not necessarily true :-) The more the panels, the more likely it is that some dimensions are shared, so it's useful to share model attributes across tiles to minimize GPU memory transfer time, already a serious latency component with singular panels. IOW it's a bit like |
@monfera are there best practices of sharing model attributes? I can think of providing |
@dfcreative with
|
Also @dfcreative we should make sure that all items in https://github.com/plotly/plotly.js/milestone/3 are ✅ in gl2d v2. |
Along with this transition - or perhaps even better before it - we should find a way to test webgl plots in iOS - perhaps using https://www.browserstack.com/screenshots/api ? We need to make sure that bugs we've fixed before - such as #280, #1868 (any others that are iOS-specific?) - don't come back with this rewrite. |
regl-error2d, faster and w/o memory limitations. Should say working with regl is pure pleasure. |
Dropping from the |
please support one context for many charts as we are hitting limitations when using newest scattergl with many charts (1.33.x) |
Same issue, we are hitting this limit in Chrome and FF very fast. IE renders 30+ webgl charts easily. Hope this can be fixed soon. regards |
@sgentile @longjohnhard please subscribe to #2333 for the latest news on that front. |
Hello guys, maybe i found an issue. function drawFramework() {
...
...
if(!fullLayout._glcanvas && fullLayout._has('gl')) {
fullLayout._glcanvas = fullLayout._glcontainer.selectAll('.gl-canvas').data([{ the data for each gl-canvas is recreated in any case even if there is already a data with a regl reference. module.exports = function clearGlCanvases(gd) {
var fullLayout = gd._fullLayout;
if(fullLayout._glcanvas && fullLayout._glcanvas.size()) {
fullLayout._glcanvas.each(function(d) {
if(d.regl) d.regl.clear({color: true, depth: true});
});
}
}; I hope this helps. |
@VinceX can you open a separate issue with a fully reproducible example. Thank you! |
This issue has been tagged with A community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort. Sponsorship range: $150k-$160k What Sponsorship includes:
Please include the link to this issue when contacting us to discuss. |
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson |
The time has come to 🔪 the gl-vis project.
These multiple small modules are becoming harder and harder to maintain. A lot of helper methods are currently duplicated across several modules - which is adding a lot 🍔 to our bundle size.
@mikolalysenko's new WebGL framework
regl
solves a lot of long-standing gl-vis issues such as multiple scopes per gl-context and improved memory management.I placed this issue on the v2.0.0 milestone because it might be a good opportunity to make the switch in-phase with bumping
d3
tov4
but this is subject to change.@dfcreative @monfera @bpostlethwaite
The text was updated successfully, but these errors were encountered: