Bug: web rendering can't keep up on long drag

[jamoore]

• On slower connections between web & server
• Load a big image
• Grab red box in bird's eye
• Click and drag it
• First few images are shown during dragging
• Eventually, rendering doesn't keep up drag speed and only gray is shown
• Release mouse somewhere
• Watching the OMEROweb.log (with debug on) you can see all the tiles being loaded for the intermediate (gray) locations.
• After many seconds if not a few minutes, the drop location is finally displayed.

I would expect that users would only want the final location shown if rendering can't keep up with the drag speed.

If have not checked the same thing on insight yet.

[atarkowska]

What server, environment?

[jmoore]

OMERO.web locally, OMERO.server on gretzky.

[atarkowska]

That's why is so slow. Development server is one thread only.

[jmoore]

Sorry, I should have been more clear. I was running under nginx.

[jmoore]

Further, even if there only is one thread, I wouldn't think OMERO.web should be loading all the intermediate items. Once it can't keep up, some load events should be dropped.

[Will Moore <will@…>]

(In [bbcc4836ac122f120d5638f2f1a6d6a3969f0b7b/ome.git]) Move instantly to ROI location (don't scroll). See #6850

[saloynton]

This issue is not able to be fixed for the 4.4 release and so is being moved into 4.4.1 release. (Discussed in web meeting 4 June)

[jmoore]

Saw this without an owner. Passing to you, Will.

[jmoore]

See also #10272

[wmoore]

The problem here is that we don't have a way (that I know of) to cancel a request for a tile. I think that tiles outwith the viewport are being destroyed on a long drag, but that doesn't stop the request for their src image.

One option we could think about was to add a timeout of E.g. 0.5 secs or 0.25 secs when a tile is added to the viewport and not to load the tile image until after this timeout. This means that the images will not be requested if you are scrolling tiles in and out of the viewport quickly. But still could be tricky. And it would mean that in normal usage, there was an extra delay every time you move the viewport before images are requested.

When I looked at this a while back, I couldn't find any callback that would tell us when a tile is loaded - so we never know what the 'backlog' is of tiles we're waiting for (how many are currently 'loading')

[jamoore]

Passing off to Ola who is looking into a possible solution.

[atarkowska]

Fixed in ​https://github.com/openmicroscopy/openmicroscopy/pull/1529

[Aleksandra Tarkowska <A.Tarkowska@…>]

(In [31355d79fb2229ca5659f62416fbacaa91b014ef/ome.git] on branch develop) adding delay before positioning tiles in the viewer, see #6850

this will prevent from loading tiles when user triggered another action
for example: if user zooms using mouse-wheel it will load only
tiles from the final level rather then all levels

[Aleksandra Tarkowska <A.Tarkowska@…>]

(In [98629993302ac4962bae81893015a47020680510/ome.git] on branch develop) fixing delay param in bird eye, close #6850

[Aleksandra Tarkowska <A.Tarkowska@…>]

(In [084ca9a590fa77d6540b59b2cc3692ffea5ff237/ome.git]on branches master, dev_4_4) adding delay before positioning tiles in the viewer, see #6850

this will prevent from loading tiles when user triggered another action
for example: if user zooms using mouse-wheel it will load only
tiles from the final level rather then all levels

[Aleksandra Tarkowska <A.Tarkowska@…>]

(In [064c0fd83b40c86229ea5c628b571a07da5f4cb6/ome.git]on branches master, dev_4_4) fixing delay param in bird eye, close #6850