Hi,
My team is working on a map-based platform which requests multiple image tiles from the back-end and performs individual coloring on each pixel of each tile.
I sometimes come across a bug in which the operation function of the _ol.source.Raster_ tries to render a source (_ol.source.XYZ_), before all the tiles of the XYZ source are fully loaded. This results in the source not being rendered at all.
In the _ol.source.XYZ_'s _tileLoadFunction_ I am sending an asynchronous _XMLHttpRequest_ and my guess is that because of the asynchronous nature of this request, the _ol.source.Raster_ doesn't wait for all the responses to be received in order to render the fully loaded _ol.source.XYZ_.
Here is our use case: we are generating a time-slider in which the user can see how a particular agriculture field looked throughout the whole year. The time-slider consists of multiple small _ol.Maps_, each containing an _ol.layer.Image_, with an _ol.source.Raster_, with an _ol.source.XYZ_. In the following image you can see a small part of the time-slider, in which the field in the middle didn't load its tiles:

I am able to detect when a field hasn't loaded properly, because I have set up logs in the '_beforeoperations_' event of the raster. For every field in the time-slider that is loaded successfully, a log is sent to the console about 17 times. I guess there are 17 workers which start working on that source (please correct me if I'm wrong). However, when a field is not rendered, only one log is sent to the console.
We have checked the following possible issues:
I am sometimes able to see (using logs) that workers start rendering a source before all tiles are received (I am logging the number of responses), but this is not always the case.
A work-around for this issue is setting the _XMLHttpRequest_ to synchronous mode, but this is not a fix as it blocks the whole platform until all the tiles are loaded.
Can you please help us with some info in this? Is our assumption regarding the asynchronous issue correct? Shouldn't the ol.source.Raster wait for the source to be fully loaded? Are we doing something wrong?
Any comment on this is gladly appreciated, we have been battling with this bug for a while now :)
Are your async calls pulling the tile image or completely irrelevant to the tiles?
Hi @raiyni
Yes the async calls are pulling the tile images.
Here is our custom tileLoadFunction:
tileLoadFunction: function(imageTile, src)
{
var client = new XMLHttpRequest();
client.open('GET', src, true);
client['withCredentials'] = true;
client.onload = function()
{
var data_str = this.responseText.slice(1, -1);
var data = "";
if(data_str === '')
{
data = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNkYPhfDwAChwGA60e6kgAAAABJRU5ErkJggg==";
imageTile.getImage().src = data;
}
else
{
data = "data:image/png;base64," + data_str;
imageTile.getImage().src = data;
}
};
client.onerror = function()
{
console.log('tileloadfunction onerror');
};
client.send();
}
I am also having this issue and can reasonably reliably replicate it with a simple ol.source.XYZ using a url (so it is not the use of the tileLoadFunction).
To Replicate (tested in Chrome/FF/Edge)

Panning again by a tiny amount will redraw the image correctly

Setting transition: 0 on the ol.source.XYZ stops the faded in mis-renders but then you always just get white holes

For anyone looking for a workaround - its not ideal, but the only (hacky) way I have found is to wait for times when all source tiles to be loaded and then force a raster redraw 500ms later when the tiles always seem to be ready.
const olSourceXYZ = new ol.source.XYZ({...});
const olSourceRaster = new ol.source.Raster({...});
const tile = [];
olSourceXYZ.on('tileloadstart', (event) => {
tile.push(event.tile.getTileCoord());
});
olSourceXYZ.on(['tileloadend','tileloaderror'], (event) => {
tile.splice(tile.indexOf(event.tile.getTileCoord()), 1);
if (tile.length === 0) {
setTimeout(() => {
if (tile.length === 0) {
olSourceRaster.changed();
olSourceXYZ.changed();
}
}, 500);
}
});
This issue should be fixed in master This issue still exists in master. Can be tested with 6.0.0-beta.2 from npm: https://codesandbox.io/s/l5olw300ql
Most helpful comment
This issue should be fixed in masterThis issue still exists in master. Can be tested with 6.0.0-beta.2 from npm: https://codesandbox.io/s/l5olw300ql