moveMap does not cancel outstanding jobs

[The111]

Both JMapViewer.setZoom and JMapViewer.setTileSource call tileController.cancelOutstandingJobs, so that the job queue does not increase without bound when quickly changing between zoom levels and tile sources.

However, JMapViewer.moveMap does not cancel outstanding jobs, which means that on a slower connection, if a user moves the map multiple times in succession, the job queue can build up to a point where the tiles the user needs to be loaded (those on screen) will be severely delayed by the queue of irrelevant off-screen tiles.

[The111]

Fixed in [o29163].

[bastiK]

Does this affect JOSM?

If yes, have you tested this for slow connections? If the map is half loaded and you pan a small amount, does it still load the other half?

[The111]

Replying to bastiK:

Does this affect JOSM?

This affects JOSM to the extent that JOSM uses JMapViewer, but there are no negative affects that I am aware of.

If yes, have you tested this for slow connections? If the map is half loaded and you pan a small amount, does it still load the other half?

Yes, I've tested it with an artificially slow connection (equivalent to 33.6k modem speeds). In fact, it is for connections like this where the change will make a noticeable improvement. Small amounts of panning while loading a general area will not negatively affect the loading of tiles, since the "outstanding" jobs which are canceled with each move are defined as those jobs which have not actually begun loading yet. Jobs which are already loading will finish loading no matter what. So even if you constantly wiggle the map slightly back and forth while loading, it will still load all on-screen tiles at the same speed. However, if you do a fairly large pan, pushing all of the tiles in the queue off the screen, in the version before this change, you would be forced to wait for all those unloaded/queued off-screen tiles to load. In the version after this change, you only must wait for those which had started loading already (a number most likely equal to the max thread count) to finish loading... while all other queued off-screen tiles will be removed from the queue, allowing the new on-screen tiles to load much more immediately by virtue of being placed in an empty queue.

[bastiK]

OK, all right then. :)

[stoecker]

A side note not related to this, but a known drawback I'm aware of.

With mod_tile and on-time rendering always an 8x8 metatile is completely blocked when loading. This always fills the load buffer of JMapViewer and makes it unusable until the requests time out or are fullfilled. Maybe you find a solution for this as well (e.g. making queue size dynamic depending on the fact whether data is transfered or all tiles wait only)?

Try e.g. using map.dgpsonline.eu and zoom into an unrendered area.

[The111]

Replying to stoecker:

With mod_tile and on-time rendering always an 8x8 metatile is completely blocked when loading. This always fills the load buffer of JMapViewer and makes it unusable until the requests time out or are fullfilled. Maybe you find a solution for this as well (e.g. making queue size dynamic depending on the fact whether data is transfered or all tiles wait only)?

I'm not sure I fully understand this. I don't know anything about mod_tile, but it sounds like you are saying it renders 8x8 metatiles (i.e. 64x 256x256 tiles combined) before it can return the single tile requested from the 8x8 metatile. If this is true, it seems unavoidable that JMapViewer must wait for metatile loading. The job queue is already unbounded in size (hence the need to clear it when scrolling/zooming to new areas), and having multiple worker threads allows the client to stay busy while server loads metatiles, I think. If JMV does indeed suffer from mod_tile's behavior described above (which I'm not sure it does, or that I understand how), then increasing the max thread count in JobDispatcher potentially could help this issue (and this option is already available to users of JMV). I've tried running with max thread counts anywhere from 8 to 64 and see no noticeable difference.

Try e.g. using map.dgpsonline.eu and zoom into an unrendered area.

That site does indeed seem to suffer from very slow loading, but I'm not sure how that relates to JMV, since (a) I don't know how that web app does its client-side loading and (b) I don't observe any similar performance problem in JMV.

Please elaborate if I've missed something.

[stoecker]

mod_tile delivers either the already rendered tiles as well as calculates new tiles when requested. It always calculates an block of 8x8 normal tiles (to save rendering power) when you request one of the contained tiles. Now for a site like map.dgpsonline.eu, which is relatively new, you much more often hit the "calculate" than the "deliver" state --> It is thus slow (for the new ones :-)

Problem is, that when JMapViewer loads an area it will not only load one tile, but multiple. Assume worst case, where the center of JMapViewer is in the middle of the 8x8 block. The loader will now send maybe up to 64 requests, all for the same metatile, so all of them will block until it is finally computed. This effectively kills the queue even for panning/zooming, as it will not be flushed (requests are still active).

What is different to normal loading: The time - normal loading is much faster than the waiting time for the rendering which can take minutes.

So in the time loading is blocked by the metatile loading, even zooming and panning does not work, although probably the other tiles would be available and must not be rendered. But the requests are only sent after the blocking tile either is finished or a timeout appears.

Increasing the thread-count would have a bad influence on properly populated servers (like openstreetmap.org, where the chance is low that a non-ocean tile must be calculated before delivery), as there you would request too many tiles in parallel.

Maybe blocked requests (i.e. established, but no data) could be moved into a different queue after a few seconds?

[stoecker]

That site does indeed seem to suffer from very slow loading, but I'm not sure how that relates to JMV, since (a) I don't know how that web app does its client-side loading and (b) I don't observe any similar performance problem in JMV.

I hope you used always a new area for tests. Once you called it with whatever software the future calls will have normal speed, as no rendering takes place anymore :-)

[The111]

Replying to stoecker:

Thanks for the description, I do think I understand the theory better now, but I still can't seem to replicate it in practice from client side using JMV w/ OSM layer.

I hope you used always a new area for tests. Once you called it with whatever software the future calls will have normal speed, as no rendering takes place anymore :-)

Yes, I zoomed in to level 18 in random areas of the globe (even oceans which as you say probably aren't rendered often) in JMV/OSM and then did quick serial panning. Never did it take more than a couple seconds for the 28 tiles on my screen to display fully. Maybe the ocean tiles are easier for the server to render? But I also tried in many non-ocean areas with roads and more complex data to render, and the results were the same.

In fact, now that I try again on the map.dgpsonline.eu site, I cannot get slow performance either, using either OSM or default (Alberding) layers, which leads me to believe that the slow performance yesterday could have been related to Alberding tile server.

[stoecker]

Maybe the ocean tiles are easier for the server to render

Rendering ocean usually is as fast as delivering already rendered tiles. :-)

I'll try to setup a test for you, which shows that effect a bit better.