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

Increase line endpoint offset to .01 For Windows/Firefox SVG gradient rendering #1022

Merged
merged 3 commits into from
Apr 2, 2020

Conversation

cpsandbox
Copy link
Contributor

Description of proposed changes

First guess at fixing missing gradients on Windows 10/Firefox. I noticed a similar issue when developing the initial gradient coloring fix. This seems to be related to how updates to the DOM are handled by change.js. (React?)

The current code updates existing gradients by changing their stop values, adds new gradients if needed and removes gradients that are not needed.

This code clears all gradient definitions and creates new where needed.

Need PR to allow deployment on heroku for external testing. (I don't have a local Windows 10 machine)

Also noted: there are two hits to change.js for one change of the colorBy menu item. (not because of this update) This causes a lot of work in unneeded traversal of the nodes and recalculation of the gradients. May need a separate issue.

Related issue(s)

Fixes # 1005
Related to #897 #947

Thank you for contributing to Nextstrain!

@jameshadfield
Copy link
Member

Thanks for this fix Clint -- I've tested it and it works for me (but then, so did the last implementation!). Am i understanding correctly that we now create new defs for every single node, but only apply them (via strokeForBranch) for branches which change colour? This PR induces branch "flashes" during color changes for me, but this is acceptible for the time being if it fixes the bug.

Presuming that this does fix it on different browsers (which is really important right now), would you mind squashing the 2 commits & fixing eslint errors. I hope we can revisit this in a future PR and restore the old implementation but with more subtle fixes.

@gj262, @heliosfa & @cpsandbox would you mind checking a deploy of this PR at https://auspice-master-e4vfffeopmcatkn.herokuapp.com/ to see if this fixes it for you?

Also noted: there are two hits to change.js for one change of the colorBy menu item. (not because of this update) This causes a lot of work in unneeded traversal of the nodes and recalculation of the gradients. May need a separate issue.

Yes, please do open a separate issue! Hoping we can identify a bunch of these unnecessary renders / recomputations and get rid of them ASAP.

@cpsandbox
Copy link
Contributor Author

Am i understanding correctly that we now create new defs for every single node, but only apply them (via strokeForBranch) for branches which change colour? This PR induces branch "flashes" during color changes for me, but this is acceptible for the time being if it fixes the bug.

There is one defs section in the svg that holds all the gradient definitions. This is taken out and totally replaced on a change to colorBy or a layout change, not one defs per node. This is simply a guess that this will get Firefox to re-render all the new gradients.

I mostly needed the heroku deploy so I can use a remote Windows system to test changes.

@emmahodcroft
Copy link
Member

If it's helpful and possible, if we could make a deploy of this I can test in native Windows 10 environment! Or a local branch I can pull and try. (But deploy is easier for me, if it's possible!)

@gj262
Copy link

gj262 commented Mar 30, 2020

Hi @jameshadfield it still appears broken to me with Firefox 74 + Windows 10 in a VM (note: the resolution is not perfect in a saucelabs VM but I still think the graph should resolve better then this). Do you have a running instance where Firefox 74 + Windows 10 was working so I can see what it should roughly look like?

0003screenshot

@heliosfa
Copy link

heliosfa commented Mar 30, 2020

I have just tried the instance on herokuapp linked by @jameshadfield and a local build of @cpsandbox's master, and #1005 is still present for me as well in Firefox and Waterfox.

image

@jameshadfield
Copy link
Member

Thanks for testing @heliosfa & @gj262. I hope to have a bit of time to tackle this tomorrow. I don't have screenshots of what windows10+firefox74 should look like, but the images on #1005 indicate that there are large sections of the tree missing.

@emmahodcroft yes there's a deployment: https://auspice-master-e4vfffeopmcatkn.herokuapp.com/

@heliosfa
Copy link

No problem @jameshadfield - I'm happy to test any other potential fixes and I'll try to keep an eye on the issue and this PR. I would offer to help fix it, but I am most definitely not a web developer!

As for what it should look like, from having looked at it in a few browsers over the last few weeks, it should be pretty similar to Firefox on *nix or Chrome.

@cpsandbox
Copy link
Contributor Author

AWS has free desktops starting April 1 which will help me with development/debugging. LMK if you want a fast reversion to non-gradient branches until then.

@emmahodcroft
Copy link
Member

Thanks! Sorry I missed that. I can't work on this directly at the moment, but am happy to test new trials on a native Windows 10 + Firefox set up - though sounds like you guys might have this under control! Just ping me if I can help.

@jameshadfield Do we have any idea of how many viewers this might be affecting? What are your thoughts on rolling back until we can support properly? I don't know how long that might take - if we can maybe get this fixed quickly after 1 April (tomorrow) then might not be worth a roll-back - but if it might take a few weeks, we might want to consider it. I'm a bit torn. I love the gradients, but it does look terrible with missing branches....

@cpsandbox cpsandbox changed the title Complete replacement of SVG defs for gradients Increase line endpoint offset to .01 For Windows/Firefox SVG gradient rendering Apr 1, 2020
@cpsandbox
Copy link
Contributor Author

After finally getting a windows desktop it became apparent that changing the line offset at .01 instead of .001 would render the gradient.

I cannot determine if that is sufficient for all off the lines. I don't know if the calculation is, for instance based of the angle or just the absolute offset.

The other prospective changes were reverted. Only the increase in line offset is changed.

Waiting for re-deploy for further checks.

@heliosfa
Copy link

heliosfa commented Apr 1, 2020

On first bash with a local build, this looks promising in Firefox and Waterfox:
image

Zooming in to one of the problem areas that I used as an example in #1005, things are looking much better as well:
image

@jameshadfield
Copy link
Member

Brilliant! Thanks @cpsandbox @emmahodcroft. The solution (0.001 -> 0.01px) is tragicomic but maybe that's browser support in general. I'll test and, assuming there are no regressions, release today.

@jameshadfield jameshadfield merged commit d362dc0 into nextstrain:master Apr 2, 2020
@cpsandbox
Copy link
Contributor Author

Is this still not working?

@jameshadfield
Copy link
Member

jameshadfield commented Apr 8, 2020

@cpsandbox I had to (temporarily 🤞 ) revert to the old behavior as we had a lot of issues in narratives especially. This was #1042. In order not to waste anyone's time, i'm going to make a branch which includes the partially-working implementation and then detail a number of reproducible examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants