Observe how the projection of the image bounces around until it stabilizes and the x and y URL parameters are set to Infinity. After that, the viewer session is broken and can only be restored by something that drops the x and y URL parameters or by reloading the page in the browser.
I think it happens everywhere, especially when using software rendering. Unfortunately, due to forum constrains, I cannot upload a video demonstrating this behavior because a) the forum does not accept video files b) 4 MB limit quite severely any animated image file format (GIF and MNG turn out way too large in my case).
So, in case it is not clear what I am doing there. First, I go to the image above, then I simply zoom in by pressing + on the keyboard. When the animation stabilizes, I press - on the keyboard. The video ends when the animation stabilizes again.
Thank you! We tried to reproduce on Chrome and Firefox with or without hardware acceleration, but were unfortunately unable to. Maybe there is a specific linux or browser issue here. Any chance you can see if this replaces on MacOS or Windows?
I don’t have the dual screen but more the jagged center pictures.
It must be because of my expensive graphic card.
It is no big nuisance.
I then just refresh.
I have always had this problem, I think, with this computer.
I use Windows and Chrome.
I think I have the same problem with other browsers.
Maybe there is a specific linux or browser issue here.
Maybe, but the more I investigate the issue the more I am convinced that this is not the case. Please read more on that below.
Any chance you can see if this replaces on MacOS or Windows?
No, I do not run any MacOS or Windows machines and I do not want nor have the time to go through the trouble of setting up a Windows (virtual nor physical) machine just to test this bug. Sorry. However, I have experienced this bug on a handful of different x64 and aarch64 machines on various versions of Firefox. However, I may be able to put Opera to the test.
We tried to reproduce on Chrome and Firefox with or without hardware acceleration, but were unfortunately unable to.
I have observed that the bug becomes more apparent or pronounced when you set the CPU power governor to powersave on Linux (you can set it on the command line or use a GUI app, often a desktop plug‑in or extension). You can do something similar on Windows by setting the maximum and minimum CPU performance to 0% in the active power profile. This basically locks the CPU frequency to a minimum. Please let me know if you can reproduce this bug under these conditions on Windows too.
Another magnifying factor is the size of the view port. The larger the view port is the more apparent the bug becomes. Adversely, the smaller the view port the less apparent the bug becomes, even with the CPU locked to its lowest frequency. The bug may become even unnoticeable should the view port be small enough.
Please note, that none of the above configuration parameters should have an impact on the viewer. In other words, these configuration parameters do not cause the bug but help make it visible. The bug exists in the code despite the configuration parameters mentioned above.
So, I think this could either be a timing issue or the WebGL code is lacking some glFinish() calls in some places. It looks like the code manipulates projection parameters and/or vertices on the wrong frame buffer (front vs. back). This can happen without proper glFinish() synchronization, especially when the renderer is slow (which is basically happening with software rendering on and low CPU speeds). Note that usually (though there are exceptions) GL commands are sent much much faster than a renderer can handle, even on slow CPUs.
So, I think this could either be a timing issue or the WebGL code is lacking some 