Skip to content
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

Enable restyle to redraw parcoords #3101 #3125

Closed
wants to merge 12 commits into from
Closed

Enable restyle to redraw parcoords #3101 #3125

wants to merge 12 commits into from

Conversation

archmoj
Copy link
Contributor

@archmoj archmoj commented Oct 18, 2018

This PR enables callbacks e.g. restyle to redraw parcoords.
This fixes #3101
@alexcjohnson

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@alexcjohnson
Copy link
Collaborator

Alright, at some point we should dive in and figure out what it will take to make lineLayer.update really handle arbitrary updates so they'll be faster. But in the meantime this looks like a solid fix. Only thing we need now is a test or two showing that this fix does allow us to change line color or colorscale.

@@ -7,6 +7,7 @@ var click = require('../assets/click');
var mouseEvent = require('../assets/mouse_event');
var failTest = require('../assets/fail_test');
var delay = require('../assets/delay');
var RESIZE_DELAY = 300;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @antoinerg - bad day for circleci it seems, we were getting repeated test failures here so I encouraged @archmoj to try increasing this delay. At some point we may want to change this so we're waiting on some event (listen for plotly_afterplot perhaps?) rather than a fixed delay, that should be more robust (and usually faster!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@antoinerg What value you suggest we use here for RESIZE_DELAY now that the CI is back to normal?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't bother reducing it (if the goal is essentially to save time) - just leave it until we get around to exploring an event-based delay, rather than time-based.

@archmoj
Copy link
Contributor Author

archmoj commented Oct 18, 2018

The restyle function is tested interactively. Do we still need to create a jasmine test?

@alexcjohnson
Copy link
Collaborator

Do we still need to create a jasmine test?

Yes - especially since at some point we want to improve performance by fixing update, we should write a few tests that we can rely on during that work to ensure nothing has changed.

@archmoj
Copy link
Contributor Author

archmoj commented Oct 18, 2018

There was a test available for colorscale; so I added another one for line color.

@alexcjohnson
Copy link
Collaborator

Hmm, those tests only really verify the mechanics inside restyle and I guess that parcoords doesn't muck something up in gd.data during plotting. But I suspect that all of that worked just as well before your fix.

We need both of those tests to check what's actually on screen after the change, probably by using readPixel - similar to 156a9db I guess but in this case we care about more than just "are there visible pixels", we actually care about the color. Presumably something like the average color over the entire canvas is sufficient.

@archmoj
Copy link
Contributor Author

archmoj commented Oct 19, 2018

Yes totally agree on that.

if(d.viewModel) {
if(d.lineLayer) d.lineLayer.update(d);
else d.lineLayer = lineLayerMaker(this, d);
if((!d.lineLayer) ||
Copy link
Contributor

@etpinard etpinard Oct 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That extra ( ) style feels somewhat new to our codebase. Maybe we could add https://eslint.org/docs/rules/no-extra-parens to our lintinting rules.

@etpinard
Copy link
Contributor

If I understand correctly, PR #2415 was also the culprit for bug #3099 (fixed in #3123)?

@alexcjohnson
Copy link
Collaborator

If I understand correctly, PR #2415 was also the culprit for bug #3099 (fixed in #3123)?

Yes, most likely specifically fa1a436 parcoords create/update pattern
Another instance of update performance breaking things 🙃

@archmoj
Copy link
Contributor Author

archmoj commented Oct 24, 2018

@etpinard
For the case of FireFox, the program actually get into plot_api and Plots.cleanPlot([], {}, gd._fullData, fullLayout);. That explains why newFullLayout was empty on FireFox.
But when we define width & height in the layout the issue goes away.
Do we have any default values for width and height? Or are they declared by the browser/window when not being specified?

@etpinard
Copy link
Contributor

Very interesting. FF must not like this block

if(regl) {
// Unfortunately, this can happen when relayouting to large
// width/height on some browsers.
if(fullLayout.width !== regl._gl.drawingBufferWidth ||
fullLayout.height !== regl._gl.drawingBufferHeight
) {
var msg = 'WebGL context buffer and canvas dimensions do not match due to browser/WebGL bug.';
if(drawFrameworkCalls) {
Lib.error(msg);
} else {
Lib.log(msg + ' Clearing graph and plotting again.');
Plots.cleanPlot([], {}, gd._fullData, fullLayout);
Plots.supplyDefaults(gd);
fullLayout = gd._fullLayout;
Plots.doCalcdata(gd);
drawFrameworkCalls++;
return drawFramework();
}
}

added in #2939

Could you check if regl._gl.drawingBufferWidth and regl._gl.drawingBufferHeight are defined in FF?

@archmoj
Copy link
Contributor Author

archmoj commented Oct 24, 2018

On FF when width and height are not declared in the layout we get float values (e.g. fullLayout.width) that we shouldn't get. So they could be rounded somewhere upstream? by either floor function or another round to nearest function. What do you think @etpinard ?
fullLayout.widthXheight= [1082.05, 450]
regl._gl.drawingBufferWidthXheight= [1082, 450]

@etpinard
Copy link
Contributor

@archmoj do you need help adding a test for this thing? This is a pretty bad bug that we should merge in before releasing 1.42.0

@archmoj
Copy link
Contributor Author

archmoj commented Oct 29, 2018

Thank you! Yes actually I am working on a jasmine test for this. I would let you know.


canvases.each(function(element, index) {

if (index == 0) { // FIXME: we assumed here that the context is the first item but may be not.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the context should always be the first one, if it's not maybe other tests will fail (not just this one). No need to for an additional check.

var canvases = d3.selectAll('.gl-canvas');
expect(canvases.size()).toBe(3, msg);

canvases.each(function(element, index) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... but alternatively, you could select .gl-canvas-context instead of all three <canvas> elements

var b = imageArray[i][2];
totalRGB += r + g + b;
}
if(secondPass > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this pattern. Let's keep getGrayRatio as just a getter function and move the expect statement to down to it block below:

        var totalRGB;
        
        Plotly.plot(gd, mock3)
        .then(function() {
            totalRGB = _getGrayRatio();

            mockCopy.data[0].dimensions[1].constraintrange = [0.4, 0.6];          
            return Plotly.react(gd, mockCopy);
        })
        .then(function() {
            var totalRGB2 = _getGrayRatio();
            expect(totalRGB2).toBe(totalRGB, 'after react');
        })
        .catch(failTest)
        .then(done);

@@ -17,7 +17,7 @@
"3d-view-controls": {
"version": "2.2.2",
"resolved": "https://registry.npmjs.org/3d-view-controls/-/3d-view-controls-2.2.2.tgz",
"integrity": "sha512-WL0u3PN41lEx/4qvKqV6bJlweUYoW18FXMshW/qHb41AVdZxDReLoJNGYsI7x6jf9bYelEF62BJPQmO7yEnG2w==",
"integrity": "sha1-cXP8GX6efk28YyE0OEZwR9vIT6I=",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you undo these package-lock changes? They have nothing to do with this PR.

@etpinard
Copy link
Contributor

Now in #3178

@etpinard etpinard closed this Oct 29, 2018
@etpinard etpinard deleted the issue-3101 branch October 29, 2018 20:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something broken
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Parcoords line color restyle problems
3 participants