Frames not advancing for linked-add spot operations...
Closed this issue · 28 comments
... when commit 2d42d4b is considered.
It seems to have something to do with the recent upgrade to bigdata-core-9.X because
- I couldn't trace any recent change in the
AddSpotAndLinkItclass - an especially the here it does not advance the view
- and a bit below the wrong time point is read out
As a consequence, it creates new linked spots in the same timepoint... breaking all assumptions and making TrackScheme behave funky in result
Besides, at least on my (updated, recent) Linux the shortcuts work lazily... not every shortcut seems to be processed/captured. And when I change them in Preferences->Keymap, the change does not seem to become effective at all..
(the Mastodon shipped with Fiji works well on my box)
... linked spots in the same timepoint...
... this helped me to restore the original behaviour....
well, except that creating/adding a brand new isolated spot was still a bit of lotery
@xulman You are looking in the master branch right?
I will investigate.
The specialedit actions were always a bit flunky.
Working on it.
@xulman Could you please test this branch?
https://github.com/mastodon-sc/mastodon/tree/fix-add-and-link-actions
trying it
thanks for looking into it
hmm. so the fix-add-and-link actions branch is better :-)
noW, the adding spot forward and backward works
but we're still facing "ignorance" to keystrokes in BDV windows... sometimes it helps to click into the window, sometimes I have to click on a spot (focus-redish it) and only the it listents.. e.g. to N,M (adv. time point),
I also managed to get it out of sync with the TS window (were lock-groupped),
the most interesting moment I managed to achieve (this was there on master too) that BDV was "autoplaying" soimething... was like frozen initially, not reacting, then clicking the group lock was the trigger and after it felt as if all actions that I wanted to do earlier while it was pretending frozen were suddenly implemented... the window content was moving rather fast, couldn't really tell if it was replying what it was supposed to do but had not done until now.. also this autoplay felt inifinite, like after doing the show it started again the same show
and I cannot escape the feeling that the recent version is slow... I don't have a bad computer here, the datset is small, no swapping, etc.. even compared to inspecting the very same data on the very same computer but with Mastodon that comes with FIji... the master or the above-mentioned branch is just slower, the responses come later
Ok this is serious.
The same branch should have a fix that gives the focus to the Display object immediately. At least for me it works.
More important about your feelings: Do you have time to make them quantitative?
There are 15 beta versions of Mastodon. If you have a metric for responsiveness, would you care to make a graph of this metric as a function of the version?
Argh this is terrible.
@xulman Could you debug what happens in the ViewerPanel.nextTimepoint() previous timepoint.
It could be related to this commit which fixed infinite event loops occurring with Linux under certain conditions, see https://gitter.im/bigdataviewer/bigdataviewer-core?at=5e7de523603fa11158273295
This fix is included in bdv-core 9.0.1. That's what you use, right?
Maybe there is interplay with how we do the timepoint synchronization between Mastodon windows. Is the "ignorance" to keystrokes in BDV windows also happening if just one BDV window is open (no TrackScheme or other BDV windows to synchronize with?
Maybe there is interplay with how we do the timepoint synchronization between Mastodon windows.
I think there might be something like this under the hood. Because I noticed a new symptom:
Sometimes when I browse time in a BDV view (with the slider or moving through a track with up and down arrow), the BDV view will start 'shaking' uncontrollably. I will try to capture this event, but it does not seem perfectly reproducible.
yes, I was using 9.0.1 bdv-core
I'll try to debug the nextTimePoint() and tell you, but I didn't notice anything wrong there last time (if it was the same method I was looking into...), only that the view did not learn about the new time point (which is why I tried to insert the .paint()...), aha, also renderer didn't know about the new timepoint (which is why I had replaced it with the other way of getting the current time point)
yes, Deborah's symptoms are the same, indeed it might have been that dragging time-slider was the trigger for the erratic show, I'll check that (and try to record the video)
one more TODO for Vlado: test "ignorance" when in single BDV view, esp. w/o group-lock
the GUI measurement, hmm, there probably tools out there to test GUIs... maybe we can measure it out from the video recordings (one can split video into tons of pngs, and manually decide when the event was triggered and when it was done and report how may pngs were inbetween)
For GUI measurement: Maybe just start first by testing if your feelings of slower responsivity persist if you downgrade Mastodon version.
yes, I actually tend to say that Mastodon (mid 2018) that comes with Fiji is okay (a reference), now I'm hugging Mar-2020 (snapshot 15) that feels okay too (it is still bdv-core-7.x), but the latest master-branch (snapshot 17 I believe) feels a bit laggy (bdv-core-9.x)... it is most likely that there's is some syncing issues in 9.x series that is just killing my experience... just thinking aloud
sorry for my spelling, I'm probably lightly disgraphic...
@tinevez @xulman I found a potential cause and tried to fix it
bigdataviewer/bigdataviewer-core@bf0df6b
Sometimes when I browse time in a BDV view (with the slider or moving through a track with up and down arrow), the BDV view will start 'shaking' uncontrollably. I will try to capture this event, but it does not seem perfectly reproducible.
This seems fixed for me now.
Could you try to run with this (you need to update bigdataviewer-core version to 9.0.2-SNAPSHOT) and report whether it fixes your issues? If so, I'll make a 9.0.2 release...
@tpietzsch Seems to be fixed by your changes. 👍
Ok, I released bigdataviewer-core 9.0.2 and mastodon master depends on that now.
@xulman it would be cool if you could check whether that fixes your issues too...
@tpietzsch Please also consider this branch, that fixes other problems Vlado found:
https://github.com/mastodon-sc/mastodon/tree/fix-add-and-link-actions
fell ill (nothing bad, just regular cold, but tears/water in eyes, hard to stair into a screen), progress slow, will test definitely and let you know here (sorry for complications)
and thanks for the fixes!
hello, me back again
I've just tested the most recent master (871e7d7), that is bdv-core-9.0.2 and the fixes (cannot add beyond time point span, add linked spot does not add into the same time point), on Linux, Windows and Mac... and it works very well!
also the issue I had with ignorance of the new shortcuts and missing key hits, all seems to be gone now
also responsivity feels good (but still open to benchmark it, have some idea)
ohh, yes, I was also testing/trying to trigger the "erratic movement" of the BDV (what Deborah noticed too) and I did not manage to trigger it again (and I believe I was doing the same thing as last time), tried with windows synced and also for isolated windows
last comment, congrats: "Mastodon distro" (git clone mastodon-sc; cd mastodon-sc; mvn clean dependency:copy-dependencies package; du -shc target/dependency) got a lot slimmer now (around 45 MB, was 100+ MB), very nice
Thanks!
Can we close this issue, or do you want to report more about your forthcoming benchmarks?
ATM I don't have anything to add to it.. just rebased my current work against the latest master commit, and shall see in the days to come if there is still some bug left... if found, I'll start a new fresh issue
the same for the benchmarks... once they avail, I'll start a new clean issue
so from me, I'd close it