1. A concise explanation of the problem you're experiencing.
I tried to publish the data in CityGML format to the web using 3DcityDB and 3DcityDBwebclient. Using 3DImporterExporter tool I successfully convert the data to KML/COLLDA format. By using Add layer option in 3Dwebclient page (index.html) I published the Collada-Json file to create scene URL. Here I am facing some problems:
When I load my entire data after some time I encounter the error "Render has stopped" with the following error, if I load partial data it is working fine.
Kindly help me to fix this.
An error occurred while rendering. Rendering has stopped.
DeveloperError: Expected width to be greater than 0, actual value was 0 Error
@GeorgeZZW The error “Expected width to be greater than 0, actual value was 0” can have many reasons. (From my experience, it usually means that some GL context was lost due to some rendering error or an out-of-memory situation, but there are more). It is very unlikely that the reason in your case is the same as it has been in this thread 5 years ago. Maybe you can open a new thread with detailed information about your setup (including your CesiumJS version), and preferably a Cesium Sandcastle where the error appears.
Hi, i found this mistake too. Could you fix it?
There is a demo, Click the “testButton”, then click the close button on the upper right corner of the dialog to close it. Repeat this operation 16 times, and the error shown.
Admittedly, I was a bit surprised to see that this happens after clicking exactly 16 times. I wonder why it is exactly 16 (apparently, not depending on the environment of browser/OS/GPU…). But from that example, this looks like a clear-cut bug, i.e. a memory leak. So this specific case may warrant some further investigation.
This is a problem I have discovered that always occurs. Other situations can also cause it, for example, when using a WebGL video player, repeatedly turning the player on and off can also lead to this error in the Cesium viewer. In conclusion, when there are multiple WebGL elements on a page and the initialization and destruction operations are executed multiple times, this error is very likely to occur.
There are some details (in fact, many details) that have to be investigated. But the problem description (for CesiumJS as well as for any other WebGL-based application that exposes this behavior) sounds like a clear cases of a memory leak.
A pseudocode(!!!) loop like
while (true) {
const viewer = new Cesium.Viewer("cesiumContainer");
waitUntilSomeStuffIsLoaded();
viewer.destroy();
}
should run forever, and never use more memory than during a single creation of the viewer, and of course, should never bail out with a lost GL context (which is what leads to the error message in the title here).
Or to put it that way: I’m pretty sure that viewer.destroy() is missing something, and not destroying some texture that should be destroyed by this call.
(Analyzing which texture that is, and how it could be destroyed, is the more time-consuming part here…)
I just wanted to have that connection. When someone finds this forum thread (for example, via a websearch), then it could be helpful to find possible solutions or workarounds that have been posted in the issue report.
Hi, I found that using a third-party library can solve the problem of repeatedly creating and destroying viewer instances, but I don’t know the principle, and i’m not sure if using this library will have any unintended consequences. Would you mind reviewing this?
Here are the key codes and demos：
// step 1 "https://github.com/plotly/plotly.js"
<script src="https://unpkg.com/virtual-webgl@1.0.6/src/virtual-webgl.js"></script>
let viewer = new Cesium.Viewer(cesiumContainer, {
contextOptions: {
// step 2
requestWebgl1: true,
}
});
// Using the above method, no errors will be reported even after hundreds of executions
@Willian I can not quickly give profound advice here.
From quickly looking at the description at GitHub - greggman/virtual-webgl: Virtualize WebGL Contexts it looks interesting, but am not sure whether it is “the way to go” here. It looks like it could be a workaround that may help to avoid the issue, but it might come at a cost. First of all, there is that requestWebgl1:true part that may have certain implications, like certain features not working reliably, or decreased performance. The performance implications of this “virtualization” in general are not clear to me. (I’d have to look very closely at what this library is doing under the hood - and won’t claim that I’d immediately understand that ). And eventually, I don’t know whether it really solves the issue, or just ~“avoids” it to a certain degree. (For example - just as a wild guess - you might receive the same error message when you create and destroy the viewer not 16 times, but more times (like 16x16 or so…))
Following up on the WebGL context release issue - would it be possible to expedite a fix? We’re facing serious implementation challenges due to this.
Additionally, before the error occurs, the console always shows the warning:
“WARNING: Too many active WebGL contexts. Oldest context will be lost.”
Can be easily simulated using:
This has been one of ~100 open tabs for a few days now, and to not leave this unanswered
I personally do not set the priorities for bugfixes and features. But given that …
the error is fatal, in that it is not ~“a small rendering glitch”, but really breaks the whole application
the conditions and reasons for when and why the error occurs seem to be somewhat clear (unless I’m overlooking something)
the fix might be easy in terms of “number of lines of code that have to be changed” (it’s not a fundamental design flaw that has to be refactored out, but most likely consists of inserting some destroy() call at the right place)
I agree that this should be considered rather sooner than later. I’ll bring it up again, and in doubt, I will try to allocate some time to investigate this. The difficult (and unpredictable) part is: Where exactly in the code does this (hopefully) ‘easy fix’ have to be inserted? So I can hardly make promises at this point.
Usually, we try to keep the connection: When an issue is reported in the forum, and then escalated into an issue in the CesiumJS repo, the issue description contains a link to the forum thread. Similarly, subsequent forum threads (where the same issue was brought up) are linked to the issue description, and vice versa.
The goal is to make sure that when the issue is fixed, there can be a response in the forum thread, saying when and how the issue was fixed, to make sure that people who stumble over the forum thread can find the solution (e.g. the version number that contains the fix).
. Could you solve this kind of problem?
). And eventually, I don’t know whether it really solves the issue, or just ~“avoids” it to a certain degree. (For example - just as a wild guess - you might receive the same error message when you create and destroy the viewer not 16 times, but more times (like 16x16 or so…))