') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Fix stacked area layering and deletion bugs by alexcjohnson · Pull Request #3005 · plotly/plotly.js · GitHub
Skip to content

Fix stacked area layering and deletion bugs - #3005

Merged
alexcjohnson merged 4 commits into
masterfrom
per-stack-first
Sep 14, 2018
Merged

Fix stacked area layering and deletion bugs#3005
alexcjohnson merged 4 commits into
masterfrom
per-stack-first

Conversation

@alexcjohnson

@alexcjohnsonalexcjohnson commented Sep 13, 2018

Copy link
Copy Markdown
Collaborator

Lumped fixes for #3002 and #3003 into one PR, since they touch the same code.

  • Issue with fill in stackgroups #3003 had two related components. First, which trace is "next" when we fill between two traces (and if there even is a next or should we fill to zero), stacked or otherwise, needs to take account of stackgroup. The "next" trace must be in the same stack group, or no stack group. Second, once you've done this, it doesn't make much sense to preserve the trace ordering as it is in gd.data exactly. Traces in the same stack group, or that fill to each other, need to be in consecutive order - or you can get weird effects like Issue with fill in stackgroups #3003 (comment). As mentioned there, I chose to push traces only backward to meet the first in their stack, but otherwise to preserve the existing order as much as possible. The new mock demonstrates this.
  • Error when deleting traces with stackgaps #3002 pointed out that we were actually redrawing points even if we were about to remove their trace entirely! So not only does this work now, but deleting scatter traces will be faster in general now.

@alexcjohnson
fix#3003- fill and layering for multiple stackgroups and unstacked …
37ee992
…scatter traces
@alexcjohnson
fix#3002- allow deleting stack groups
f6c5d56
and along the way speed up trace deletion in general, by not redrawing
all the points in the deleted trace immediately before removing them!
alexcjohnson
alexcjohnson commented Sep 13, 2018
View reviewed changes
Comment threadsrc/traces/scatter/plot.js
});
} else {
scatterLayer.selectAll('g.trace').each(function(d, i) {
join.each(function(d, i) {

@alexcjohnsonalexcjohnsonSep 13, 2018

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

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

@etpinard it doesn't seem like animations can remove traces, is that correct? That's what it looks like, since I don't see a join.exit() associated with them (since isFullReplot = !transitionOpts)... yet the comment above implies that you can add traces:

// Must run the selection again since otherwise enters/updates get grouped together// and these get executed out of order. Except we need them in order!

So... do I need to worry about animations deleting traces or not?

@etpinardetpinardSep 13, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

do I need to worry about animations deleting traces or not?

Right, removing traces with 'frame.redraw': false (i.e. without a replot at the end of the animation), doesn't work currently:

peek 2018-09-13 16-17

https://codepen.io/etpinard/pen/ZMRReB

so I don't think you broke anything here.

@etpinardetpinardSep 14, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ah Ricky wrote an issue about this #932

@alexcjohnson

alexcjohnson commented Sep 13, 2018

Copy link
Copy Markdown
CollaboratorAuthor

@etpinard 3rd time's a charm, but the intermittent error in test-jasmine2 (that came in with the context loss event PR?) has been rearing its ugly head...

@etpinard

etpinard commented Sep 13, 2018

Copy link
Copy Markdown
Contributor
  • First, which trace is "next" when we fill between two traces (and if there even is a next or should we fill to zero), stacked or otherwise, needs to take account of stackgroup. The "next" trace must be in the same stack group, or no stack group. Second, once you've done this, it doesn't make much sense to preserve the trace ordering as it is in gd.data exactly. Traces in the same stack group, or that fill to each other, need to be in consecutive order - or you can get weird effects like #3003 (comment). As mentioned there, I chose to push traces only backward to meet the first in their stack, but otherwise to preserve the existing order as much as possible. The new mock demonstrates this.

Nice solution! Would you mind adding a few words about this behavior in the fill attribute description?

@alexcjohnson

alexcjohnson commented Sep 13, 2018

Copy link
Copy Markdown
CollaboratorAuthor

Would you mind adding a few words about this behavior in the fill attribute description?

Good call, I added it to both fill and stackgroup -> fe0c988

@etpinard

etpinard commented Sep 14, 2018

Copy link
Copy Markdown
Contributor

nicely done 💃

@alexcjohnson
alexcjohnson merged commit e545415 into masterSep 14, 2018
@alexcjohnson
alexcjohnson deleted the per-stack-first branch September 14, 2018 13:07
This was referenced Sep 14, 2018
Closed
Closed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@etpinardetpinardetpinard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

bugsomething broken

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@alexcjohnson@etpinard