According to the docs, texture.needsUpdate = true; causes the texture to refresh when it is next used.
Is there any way to find out if this has happened?
The reason I want to know is that I’m seeing a bug on a specific piece of hardware: I update a canvastexture and set needsUpdate = true, but the texture doesn’t update. If I set a delay before setting needsUpdate, it updates successfully. However, I want to limit the delay, so I want a way to poll when the update has happened and then fade in the material.
polling is a sure fire way to screw up the app, it creates race conditions. one of those must have caused the bug, starting a new race doesn’t seem ideal imo. could you go into how the material is formed and updated, and how it happened that you don’t know when?
I think the expectation is that the texture updates synchronously, and immediately, the next time you render any frame in which the texture is used by a material visible in the viewport. If that doesn’t seem to be happening it may indicate a bug, possibly in the hardware APIs. Would you be able to share a demo and details on affected hardware?
The hardware is a piece of digital signage kit by samsung. My understanding is that the guts are similar to a raspberry pi 4 and the browser is a fork of Chrome 56. Unfortunately there are no console/debug tools in the browser, so it’s been a bit of a pain to debug.
I got around the problem by running needsupdate every frame. It’s a total cludge fix, but doesn’t cause me any performance issues & fixes the immediate problem.
I’m creating a canvas as a buffer for a UI. When the buffer is required, I load a 1024x1024 background image. I wait for the load to complete, then I clear the buffer and draw the image, followed by a load of UI text. Then I set needsUpdate to true and fade in the material.
I’ve verified that the image is loaded & ready, often I get the old contents of the buffer instead of the new. Then next item, I get the content I just tried to create. So I’m always (or mostly) a step behind. Sometimes delaying the needsUpdate by half a second will fix it (with an ugly jump), sometimes it won’t.
What’s really interesting, is that I don’t see any jumps with my fix (setting needsUpdate true every frame) and it’s 100% effective.
I’ll do my best to put together a demo, although as I mentioned, it’s only ever been a problem on the target hardware.