Navigating using the slider has unexpected effects

[hspitzer]

I have a dataset of about 100 slices with annotations on most of them.
When moving through the dataset using the slider, sometimes the annotations that are loaded do not fit the image. Sometimes an annotation from another slice overlays the current annotations. I guess that it has something to do with initAnnotationOverlay() being called again before the previous execution is finished and thus resulting in an incorrect configuration of the paper canvas.

I will ask our masters student, Karsten, to have a look at it, however I'm also open for suggestions.

[r03ert0]

We should prevent series of slice annotations to be loaded. A quick fix could be to verify, once annotations were loaded, that we are still in the same slice (currentImage) from where the load was launched. If that's not the case, we do not add the annotations to the slice.

[r03ert0]

Hi Hannah,

Commit 75ec636 should solve the 'binge loading' issue. I defined a 'annotationLoadingFlag' that's true when an annotation is loading. If loading is finished or if it fails, annotationLoadingFlag goes false, and further annotations can be loaded. I also check once an annotation has been loaded if the currentImage is the same that the annotation was ment for. If that's not the case, then the code calls itself to get the currentImage. For example: imagine that you are moving the slider and it goes all the way from 1000 to 1500 where it stops. The code will load a bunch of annotations in between 1000 and 1500. Let's suppose that the last one was 1495, and that it finished loading after the user stopped fiddling with the slider. In that case, the annotation loaded will be that of 1495 but currentImage will be 1500, and the code will auto-load the annotation for currentImage=1500.

I also added the code to save multiple-slice annotations. To prevent saving annotations from slices that haven't changed, I am now saving a hash obtained from the Regions. Before saving I recompute the hash. If it hasn't changed, I don't save anything. If it has changed, I update the hash to the new one and save the file.

There was one last issue with multi-slice saving. I was using myTimestamp (time of saving) as Primary Key for the database. When saving multiple slices, myTimestamp will be the same for many of them, and mySQL will refuse to save them. To solve this I had to add a new UniqueID integer column to the database which is now the primary key instead of myTimestamp. I'll add the updated database code in a second.

I'll close the issue, but feel free to open it again if you find a bug.

[hspitzer]

Thanks! Looks good, but I will have a close look at it tomorrow.
Regarding the code for saving, I fixed a bug that would overwrite not yet loaded annotations in #34

[hspitzer]

Unfortunately, this is not working for me. The annotationLoadingFlag is never set to true, so this might be part of the problem :-)

There are actually two problems when navigating with the slider:

1. The old paper canvas is not hidden correctly and
2. Annotations are loaded two times from the db

For 1. I might have a solution: Instead of hiding the previous slide only when initAnnotationOverlay is called, I am now calling a new function hideAnnotationOverlay from loadImage (which happens before the loading of the actual tile source). In #40 you can see these changes.
For the second problem, I am not quite sure how to do it. Maybe when the annotationLoadingFlag works properly, it solves this?

Btw, the log message when saving always outputs the name of the last slide. But it should display the name of the saved slide...

[r03ert0]

the log message displays always the last value because that is the value of the 'sl' variable at that time. We should use a closure to generate a local copy of 'sl' at the time when the ajax call is executed... (this will not change anything to the execution, though).

[r03ert0]

is this still an issue?

[hspitzer]

It was fixed with #48 by disabling the loading of images until the slider has stopped. Only for IE there still might be problems.