0:2(12): error: extension `GL_EXT_shader_texture_lod' unsupported in fragment shader
GetShaderSource() ->
#extension GL_EXT_shader_texture_lod: require
void main() {}
Console
Imports need some attention:
WARNING: Multiple instances of Three.js being imported. main.aa7a8648d60f5eee.js:2023:683951
I think the following should be logged at .info() level:
system ERROR in CurrentUserService.reloadCurrentUser() No accessToken and/or userId in local storage main.aa7a8648d60f5eee.js:1:551236
Traffic sign sprites missing:
Image "information--general-directions--g1" could not be loaded. Please make sure you have added the image with map.addImage() or a "sprite" property in your style. You can provide missing images by listening for the "styleimagemissing" map event. main.aa7a8648d60f5eee.js:2087:596491
Image "complementary--texts-three-lines--g1" could not be loaded. Please make sure you have added the image with map.addImage() or a "sprite" property in your style. You can provide missing images by listening for the "styleimagemissing" map event. main.aa7a8648d60f5eee.js:2087:596491
Image "regulatory--texts-four-lines--g1" could not be loaded. Please make sure you have added the image with map.addImage() or a "sprite" property in your style. You can provide missing images by listening for the "styleimagemissing" map event. main.aa7a8648d60f5eee.js:2087:596491
UI
The Image by <username> for <organization> attribution components are no longer links.
Thanks for letting us know! BTW, which browser/OS are you using? I can’t see the WebGL-related message on my system. I’ll look into the other console warnings.
The UI change is recent as the user profile now switches to the image owner when an image loads automatically so it was deemed no longer needed. Do you think it would still be useful?
Right, that’s what I would I suggest too. However, for the sake of orthogonality I would reinstate both links, unless it requires unreasonable technical effort or performance penalty.
I AM REALLY FED UP WITH THE WEB APP’S PATHETIC PERFORMANCE WHY DO OTHER WEBSITES LIKE RAPIDEDITOR.ORG GET IT RIGHT AND YOU DO NOT FOR YEARS
Guys, we all have been really patient and everything but this just cannot go on. It is a massive pain to do anything in the web app. Everything is so sluggish and slow that I just cannot comprehend how this passed QA or any supervisor for years. I have reported this pathetic chewing gum performance many times over and over for years, with CPU load graphs and everything. I have even hinted at what the cause may be. Nothing has happened. Instead, things got even worse. Why does a website like Rapid Editor get it right to integrate the same imagery and Mapillary does not? Guys, not everybody accesses the web app using a Mac M5 Pro or GeForce RTX 5090. Are you not aware that most people these days use low power and low performance mobile devices to access the web app? These kinds of devices have limits, you know! The web app is not the latest next-gen triple A game smash hit either. But, the worst thing about it is not even the pathetic performance itself but the fact that this grudging performance has a direct bad impact on many functions a user can do, like Time Travel (selected image to compare jumps back to an image viewed before), zooming in and out of an image (immobilizes panning in the viewer), updating the node on the map layer to the currently viewed image (lags like 30 seconds behind), accessing the calendar day picker in the filter, traffic signs, and point features (freezes the whole app until things have been loaded), viewing traffic signs and point features on the default Mapillary map layer (in this case you better make yourself and come back in the evening). To get anything meaningful done, since about a year now, I always have to switch to the OpenStreetMap map layer because it is the only map layer that at least slightly eases the load to be able to do anything. I have even tried tuning some internal Firefox settings to see if the issue may be on my side of things but no. Mapillary web app performance just sucks! In other words, basically no other WebGL app that I use has this kind of horrific performance issues. I am appalled and mad. I am not mad at the web app itself but at the fact that nothing has happened for years and nobody really seams to care about this.
Thank you for your honest feedback. I understand your frustration with the Mapillary web app’s performance, especially on lower-powered devices. With the amount of images uploaded to Mapillary growing over time, the amount of data that is visible and the overall memory usage has been increasing. One of the ways we’ll address this issue is by introducing a new way of how we display coverage on the map. This should reduce load times and overall memory consumption of the map leading to more responsive usage of the whole web app. Stay tuned for more updates.
I am not as much concerned about loading times as about rendering performance. Although loading times are surely going to become an issue over time, it is rendering performance that has bothered me ever since. Why? Because rendering performance directly impacts usability. In many parts the web app feels like chewing gum and thus is a pain to use. The amount of data it displays is not the root cause for its poor performance but rather its design in how it uses WebGL. It uses multiple rendering contexts simultaneously on one GPU and stacks layers with huge swaths of alpha blending. Both things are really slow operations on most GPUs. Although some desktop GPUs do support hardware context switching, it is not a good strategy in general to have multiple contexts ultimately present their render targets in one final window. Unless you are aiming for stereoscopy, employing multiple GL contexts on one GPU for one presentation target only usually means that you are doing something wrong. In fact, you can modify multiple buffer objects or the same buffer object concurrently in a single context if you need to. All you have to do is just synchronize buffer object access. But, creating multiple contexts just for the sake of concurrency (or higher level abstraction beauty) is a misunderstanding.
The web app is indeed beautiful but beauty alone is not enough for good usability. I do understand that you have to care a lot about the backend. But, the frontend is also in desperate need of some performance attention.
Although this is not a bug per se, it is bothering me and possibly also others for quite some time now. Location search seems to always select the oldest imagery for displaying a location. Furthermore, it seldomly chooses the best image directly viewing the location, despite often having many other better suited and newer images available to choose from in the location’s proximity. This used to work a lot better before.
The sprite sheet is loaded by the components that require it when they render so it should not block the app but it’s also loaded by MapLibre and MapillaryJS (since we show these sprites there as well) where it might be required to fully load and render the content within these components.
Oh well, unfortunately it does. Just click on the “Show traffic signs” drop down combo box in the “Map data” menu. Ridiculously enough, it does this every time because for some elusive infinite wisdom reason this resource is never cached (like it were a highly volatile resource). The same goes for point features. There is nothing wrong with loading resources dynamically but loading should never freeze the UI.
So, nothing you can or need to fix.
I AM REALLY FED UP WITH THE WEB APP’S PATHETIC PERFORMANCE 
WHY DO OTHER WEBSITES LIKE 
and come back in the evening). To get anything meaningful done, since about a year now, I always have to switch to the OpenStreetMap map layer because it is the only map layer that at least slightly eases the load to be able to do anything. 
I have even tried tuning some internal Firefox settings to see if the issue may be on my side of things but no. Mapillary web app performance just sucks! In other words, basically no other WebGL app that I use has this kind of horrific performance issues. I am appalled and mad. 
Just click on the “Show traffic signs” drop down combo box in the “Map data” menu. Ridiculously enough, it does this every time because for some elusive infinite wisdom reason this resource is never cached (like it were a highly volatile resource). The same goes for point features. There is nothing wrong with loading resources dynamically but loading should never freeze the UI.