[Proposal] A new, more unified way to identify when iTowns view is loaded and stable for testing

[airnez]

Context

During march 2025 iTowns hackaton, we identified that using the view schedueler to subdivide TiledGeometryLayer's nodes was odd. It is an almost instantaneous process, and schedueling it along network request is confusing. The PR #2521 and #2525 do attempt to adress issue #2421.

However, it does break our functionnal tests for a good reason: It becomes harder to know if current iTowns view is stabilized.

• If the test launches prematurely, some layers might be missing (the scheduler becomes empty inbetween two layers addition). For the source_stream_wfs_raster test, that's what happens. VIEW_EVENTS.LAYERS_INITIALIZED event is triggered too early.

• If a test prematurely considers that the view is stabilized, it might measure values at the wrong moment. This is the case for view_multiglobe test

• It a sub-test ends prematurely, it might influence upcoming tests. This is the case for the two failing globecontrol tests.

It is possible to handle all those specific tests. By first querying the datasources prior to view instancing, it should be possible to avoid in-between layers VIEW_EVENTS.LAYERS_INITIALIZED trigger. Listening to animations or frameRequesters helps identifying view stabilization.

It however feels like we are missing a more global approach. Something easy to tell wether or not current view is stabilized or not.

Description of the proposal

Several implementation ideas (not exclusive) :

• A specific layer property exposing wether or not a layer is currently "working"
• A new event VIEW_EVENTS.STABILIZED that properly tells when everything is set (how?)
• A new way to add layers to the view specifying beforehand what will be part of the view. (Passing layer loading promises for instance)

[jailln]

Thanks for this analysis and proposals 🙂

We indeed need to implement ways to know when the view is stable. I like the idea that each layer should have a state, e.g. "idle" and "loading". I think it may also be a good idea that each layer also throws an event each time it has finished loading in addition to the property. I also agree with the fact that the view should have the same information (a property and an event), based on 1- the layer states and 2- the camera / animation state which are the two factors producing view changes.

I guess that should be enough to handle the following use cases:

• First initialization of the view (wait for the first view initialized event)
• Camera move: (in pseudo-code) Camera.move(x,y,z).then( view.addEventListener(VIEW.STABLE, /* do stuff */) )

WDYT @iTowns/admins and @clementcolin ? Do you see any other usecases or do you have a better implementation alternative?

[clementcolin]

First of all, I'd like to mention that the current LAYERS_INITIALIZED mechanism is triggered when all layers are "ready," not when the view is stable. This means that some tiles may still be downloaded after the event is sent.

Additionally, if you look closely, some layers do not implement a whenready method and rely solely on the source whenready methods. This may be confusing, so we should definitely make this mechanism homogeneous.

That being said, I like the idea of each layer having a state (idle/loading) and throwing an event when its state changes. The view can listen to all those events to send its own event about the view state (idle/loading).

I think that camera movement should trigger another event, as the view can change with exterior user interactions such as adding a layer, selecting an object, etc.

I'm also in favor of throwing an event when the view is initialized, i.e., to keep the same mechanism that checks if a layer and its sources are well configured and available. However, we may need to redefine the notion of "ready" for a layer and a source and make it consistent for all types if possible.

To summarize my proposal:

• Each layer has a state: idle or loading (may be linked to its sources).
• The view has a state: initialized (the layers are ready but can still be loading), loading (at least one layer is loading something) or idle (nothing is being loaded, although animations such as an object moving may still be occurring), .
• The camera has a state: moving or idle (the view can easily listen and send those events if needed).

[jailln]

It seems we all agree on this! @clementcolin would you be available to work on that ?