matsengrp / olmsted

B-cell repertoire and clonal family tree explorer
http://olmstedviz.org
GNU Affero General Public License v3.0
15 stars 4 forks source link

Resize events have inconsistent effects on brush selection (via changes to width signal) #65

Open eharkins opened 6 years ago

eharkins commented 6 years ago

How to reproduce:

This becomes more dramatic when autosize:fit is used for the scatterplot, we suspect because we observe a change to the viz width that comes with using autosize:fit and everything gets shifted in order to accommodate this resize. Resizing the window should change where the brush selection is on the screen as the viz is resized, but it should not change the range of values selected within the viz, so the selected families should persist.

I opened a vega issue for this (https://github.com/vega/vega/issues/1421).

One clue as to why this happens is that the brush_{x, y} signal seems to remain consistent but the brush_{x, y}_field changes on resize. The latter is the range of values (to scale for each variable) but is derived from the former, so the problem is actually that brush_{x, y} is not changing (though unclear why brush_{x, y}_field is changing if its source is not). I believe this is happening because brush_{x, y} are just the unscaled set of coords within the viz determined when you create a new selection. These are the values actually used to draw the selection on the screen because the viz doesn't care about the x and y scales to do its job which is just drawing the box for the selection. brush_{x, y}_field is a scaled version of these values, which we bind to for our table filtering purposes. So we actually need to update brush_{x, y} on a resize since the box drawn on the screen will depend on our new width. And then the brush_{x, y}_field scaled values will follow, since they are derived from brush_{x, y}, which will allow us to keep the same data selected.

Let me know if this is needs clarification. The solution isn't obvious to me, since I'm not sure how we would recompute brush_{x, y} coords on resize based on a new width.

eharkins commented 6 years ago

This seemed more noticeable on the first resize, hence the issue name, though brush_{x, y}_field is still changing the resulting scaled values on later resizes. And in fact, brush_{x, y} is changing on resize events since it depends to some degree on the width. So maybe this just isn't happening in exactly the way we'd like. Changing the name to reflect this observation

eharkins commented 6 years ago

@metasoarous we talked about trying to recreate our brush selection / resizable scatterplot in the online vega editor to find out why we had any success with the brush selection being responsive to resizing. The IDL/Vega people pointed out (https://github.com/vega/vega/issues/1421) that it should not work at least given the brush selection signals from vega lite (or their corresponding compiled vega counterparts), so I think the idea was trying to figure out how it was working (at least partially) for us given their convincing argument about how resizing should not have an effect on the standard brush selection. Do you think this is worthwhile or should we close the vega issue and try to rewire the brush selection to be more dependent on the selected values than some exact coordinates inside the viz?

metasoarous commented 6 years ago

Hmm... it would actually make debugging of this a hell of a lot easier if we had #52, cause we could just export the exact vega spec and point them to it. I'd rather do that than spend a bunch of time coming up with a minimal example (which is 1/2 the battle of the problem). If we smooth out deploy and get some dummy data ready (#92), could maybe even just point them to a commit.

metasoarous commented 3 years ago

Note: This issue above has been moved over to https://github.com/vega/vega-lite/issues/4449