Map Data checkbox: perhaps use toggle slider instead

[nertc]

This PR addresses "Map Data checkbox: perhaps use toggle slider instead" issue mentioned in the #4931

Several changes were made to the data loading functionality:

1. Clicking "Map Data" checkbox will add loading spinner to the label. It will be shown until back end collects and returns all the information (see "Loading Video"). After all the information is returned, spinner will be removed.
2. After getting information and agreeing to show it on the map, rendering process will be asynchronous. Therefore, there will be no more browser or page freezes and it will have animation like visual (see "Render Video").
3. If user unchecks "Map Data" checkbox, removing process will be also asynchronous and there won't be any freezes. It will also have animation like visual (see "Remove Video").

• Checkbox state will be updated as soon as it is clicked, so changing it to the toggle one has no more benefits.
• If the user decides to uncheck "Map Data" while back end collects information, loading spinner will disappear.
• If the user decides to uncheck "Map Data" while objects is rendered, it won't trigger change until the rendering process is done. After the process, application will check and if "Map Data" is unchecked, it will start removing rendered objects.

Connected to the PR openstreetmap/leaflet-osm#38
Fixes #4931

Videos:

Loading Video

OpenStreetMap.and.33.more.pages.-.Work.-.Microsoft.Edge.2024-07-25.11-51-38.mp4

Render Video

OpenStreetMap.and.28.more.pages.-.Work.-.Microsoft.Edge.2024-07-20.16-55-01.mp4

Remove Video

OpenStreetMap.and.28.more.pages.-.Work.-.Microsoft.Edge.2024-07-20.16-56-42.mp4

[AntonKhorev]

Are you planning to get the changes to vendor/assets/leaflet/leaflet.osm.js merged in https://github.com/openstreetmap/leaflet-osm ?

[nertc]

@AntonKhorev Yes. Should I create a separate PR in the https://github.com/openstreetmap/leaflet-osm for it?

[nertc]

I created a PR for the leaflet-osm (openstreetmap/leaflet-osm#38) that needs to be merged before this PR will be, as asynchronous loading part depends on it.

[nertc]

This PR is linked to the openstreetmap/leaflet-osm#38. If leaflet-osm PR is not merged, this PR can't be merged.

[nertc]

PR was updated to include changes made in the openstreetmap/leaflet-osm#38. As leaflet-osm PR is now merged, this PR can be reviewed and merged.

[AntonKhorev]

Now you can check Map Data, wait for the rendering to start then quickly click Map Data 2*n times and watch how data is added then removed then added then removed... n times. While this is happening and Map Data is checked, pan to a different place to get a stream of javascript errors.

[nertc]

@AntonKhorev I couldn't reproduce JS errors in the console. But I changed logic and now when user clicks "Map Data" checkbox, previous action is skipped immediately. Therefore, there will be no 2*n loads and errors. When we will be okay with the solution, I'll create a new PR in the leaflet-osm.

[nertc]

If there are no other change requests for this PR, I'll create a new PR for the leaflet-osm to merge changes done in the vendor/assets/leaflet/leaflet.osm.js.

[nertc]

PR was updated. Branch was synced with master and conflicts were resolved. Also, instead of handling canceling layer loading in the setTimeout callback, now it is handled by clearing setTimeouts.

Optimizations for layer rendering were done in openstreetmap/leaflet-osm#43, but still this PR is relevant, because it adds loading spinner for those cases when data is processed by the back end, and also for slower CPUs (for example, when I set 6x slowdown to the CPU) it will provide smooth asynchronous loading without any freezes.

[nertc]

PR was updated. master was rebased. Conflicts were resolved. Failed tests were not impacted by this PR (for more information see #5439 (comment)).

[nertc]

This PR is linked to the openstreetmap/leaflet-osm#47.

[tomhughes]

This mostly works great - the only issue I can see is that if you enable the data layer and then reload the page then it doesn't enable the spinner while it does the initial page load though it does appear on subsequent map drags.

[nertc]

PR was updated. master was rebased.

@tomhughes Thank you for the review. Spinner issue on page refresh was fixed.

[tomhughes]

Thanks for the fix. I think this looks good now.

[deevroman]

This PR brought two problems:

1. When moving the map, a white flash occurs and all objects on the map are redrawn:

2025-03-14.02.59.29.mp4

2. Rendering slowed down. What used to occupy ~400ms now occupies ~1.3s. Hiding a data layer was previously performed on ~100ms, now ~1.5s (!)

Both problems arise due to the fact that before that the redrawing of the map was performed only once, after the completion of the removal/adding of objects to the SVG-element of the map.

I can agree that the first appearance of the data layer looks beautiful. But the work with the map worsened.

[nertc]

@deevroman Thank you for your feedback. #5799 disabled asynchronous layer loading and, therefore, there shouldn't be any flashes or slow rendering process anymore.

[deevroman]

@nertc no, #5799 disabled asynchrony not for the Map Data layer, but for the layer that shows the active object.

[nertc]

You are right, I thought, it disabled both asynchronous functionalities.
I pulled master and tested turning asynchronous loading off.

1. About flash: it is because data is loaded asynchronously and as everything is rendered one by one (and not as one operation that may cause freezing of the website), on fast machines it may be perceived as a flash.
2. About performance: these are several rendering test results from my local machine:

   3260 features | 178ms -> 328ms (~1.8x)
   3163 features | 169ms -> 264ms (~1.5x)
   2319 features | 114ms -> 196ms (~1.7x)
   

   Therefore, on average previously it was 1.7x faster (which is logical, because now it is asynchronous and is not done in one operation).

But in terms of redrawing all of the features, when map is moved, there was no change that would impact that behavior. Even after turning asynchronous functionality off, all of the features were still redrawn.

Turning asynchronous functionality off will solve flash problem, but redrawing all the features will stay the same. Though, for those who have weaker CPUs (for example when I run performance test on CPU 20x slowdown), rendering data asynchronously helps user not to have frozen web page and browser. I think, if you suggest turning this functionality off or some optimization about rendering data, it will be better to be discusses in a separate issue.

[deevroman]

What do you use to test CPU slowdowns? Test rendering >4k features.

Can you give us an example of when the user has time to notice the browser freezing, while making the user guess that they are waiting for rendering, and not downloading data?

[nertc]

For CPU slowdown I use browser built-in functionality.

Difference between getting data from server and rendering them is that while getting data, there are no CPU intense tasks and loading icon is shown next to the data layer checkbox. When rendering is started, it uses CPU to render data and may freeze application or browser.

In the video you can see when rendering data can take long time (full video can't be uploaded because of the limitations of GitHub, in reality it took about 30 seconds to render all elements). In such case, there would be 30 seconds freeze of browser if there was synchronous process.

OpenStreetMap.and.16.more.pages.-.Work.-.Microsoft.Edge.2025-03-20.12-19-44.mp4

[deevroman]

For CPU slowdown I use browser built-in functionality.

Ah, chromium, got it. 20x slowdown is unrealistic. With this value, I can't move the map normally, even without the data layer. But even with 20x slowdown, the layer with 11k features is drawn in 4 seconds when rendered synchronously on my PC.

In such case, there would be 30 seconds freeze of browser if there was synchronous process.

This is not true because synchronous rendering is faster than asynchronous rendering.

In general, I will most likely suggest a PR that disables asynchrony.