Please restore compatible graphics mode
-
@schilpat
And the rest of the requested data:Name Firefox Version 142.0 Build ID 20250811145442 Distribution ID Update Folder C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\CAD80AFE5C68F6E7 Update History Update Channel release User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:142.0) Gecko/20100101 Firefox/142.0 OS Windows_NT 10.0 19045 Application Binary C:\Program Files\[removed for privacy reasons]\firefox.exe Profile Folder [removed for privacy reasons] Build Configuration about:buildconfig Memory Use about:memory Performance about:processes Registered Service Workers about:serviceworkers Third-party Modules about:third-party Launcher Process Enabled Multiprocess Windows 1/1 Fission Windows 1/1 Enabled by default Remote Processes 28 Enterprise Policies Active Google Location Service Key Found Google Safebrowsing Key Found Mozilla Location Service Key Found Safe Mode false Memory Size (RAM) 63,9 GB Disk Space Available 198 GB Profiles about:profiles Pointing Devices Mouse -
Hi @rdo118 , thank you for the information. That is really weird behaviour considering you are running on high-end HW. That might be a SW issue, from bad drivers, bad OS version, to bad browser version. The issue can affect only specific instructions/operations, which might result into a smooth demo scene but a laggy Windy.
Could you please try a different browser than Firefox? Ideally chrome-based. Thank you!
Alternatively, you could try updating your GPU drivers
-
@schilpat
The problem is in Chrome as well (as I mentioned in my original thread https://community.windy.com/topic/41479/map-is-extremely-laggy-since-the-latest-update/2?_=1755883381930), but it doesn't look exactly the same. Firefox seems to perform the change (zooming in or out or moving a time step), then pause for half a second to a second with a very low-res version of the map, and then draw everything. Chrome seems to do a pause initially, then do the zoom or move, then draw quickly. It's not quite as slow as Firefox, but still much slower than normal, though when I say "normal", I mean how it used to be in Firefox. I detest Chrome and never use it other than for occasional sites that have Chrome-specific features and don't work in Firefox.I'm on a slightly older driver due to compatibility issues. Nvidia has had a long string of drivers that have messed up a few things, which has made me wary of updating. But drivers from the beginning of this year shouldn't be too old for a modern website. My mobile hasn't had an update of any kind in over a year, and it works fine there.
Well, it was a good run. Maybe time to find an alternative. I've enjoyed Windy, but it's unusable now, and I'm reading between the lines that this is how it is going forward.
-
I idefix37 referenced this topic on
-
@schilpat
I'm now on the latest GPU drivers. The laggy behavior is exactly the same.
Something is clearly wrong with your implementation, as this is the only site where this happens. -
Clearly, this is an issue they're actively ignoring. Either due to incompetence (i.e. "we've started using a function that we've implemented incorrectly but we don't know how to fix it") or because they think it's ok to break the site for a small number of users, as an "acceptable loss".
-
@rdo118 being rude will help...sure try that, yeah.
-
@Wheats They've shown that they don't care, so I'm not going to be nice at that point. They should at least be honest and state clearly that this is something that won't be fixed, and that they don't care. As of now, people could be fooled into thinking they will fix this and renew subscriptions but still be stuck with an unusable service.
-
@rdo118
Catch more flies with honey than with vinegar.My question is, with your higher end computer...why did you need to use graphics compatibility at all? I don't have a dedicated GPU and Windy runs fine.
Seems to me, that when you noticed a problem in the past but it went away when you turned on that setting is the day something went funky with how your setup communicates with the instructions/operations that Windy uses.
But I'm just a user who shouldn't even have replied in the first place lol
-
@Wheats They're obviously using a feature that isn't well supported or that they have implemented it incorrectly (or both). The old compatible graphics mode eliminated the laggy issue that was introduced in an update a while ago (can't recall exactly when as the fix was quick and easy - then). They have now, in their infinite wisdom, removed that option, and so those of us who are affected are now stuck with a practically unusable version of Windy. My browsers (yes, this affects all of them, with completely different engines) are up to date, my operating system is up to date, my graphics drivers are up to date. The WebGL demo I was asked to run works perfectly. NO OTHER SITE misbehaves. It's blatantly obvious that they've messed up, but they ignore it. Fixing it could take some time, I fully understand that. But not even commenting or responding back with a status or future plan for a possible fix, or a decision to not fix as too few users are affected (which is what I assume is the case), is just pathetic and terrible customer service.
-
@rdo118
Hi, apologies for not responding to the topic. I was on vacation. Regarding the problem you are experiencing, it is challenging for us to debug the issue, mainly because there are no obvious reasons why you should be experiencing such poor performance, considering your hardware.So first, I have a few more questions:
- Is the map laggy even when you are panning without loading new tiles - more specifically, whether the map seems smooth until new tiles are being loaded (lag spikes), or does it have bad frame times (bad fps) all the time?
- Does this also happen in radar and satellite overlays?
And second, could you make us favor and perform a little investigation within chrome devtools - in Performance tab? Simply load Windy, click Record button in the left corner and then perform some interaction with the map (interaction you reported to us as being laggy), let's say for 5-10 seconds. After stopping the recording, look for tasks that took too long and that eventually caused dropped frames. Among these tasks can be e.g. readPixels, texImage2d, texSubImage2d... And send us a screenshot of the flamegraph (including the frames row for context), ideally with a detailed view of the lag spike.
E.g. like this:
Here is a little guide on chrome flame graph. https://medium.com/slalom-blog/flame-graphs-in-chrome-devtools-a-guide-for-front-end-developers-b9503ff4a4d
Thank you for your patience and cooperation.
-
This is all about loading stuff. When I zoom or pan or use the timeline scrub for forecasts, new tiles are being loaded, and that's where it all breaks down. It takes ages, and while the interface is waiting for the new tiles, everything is frozen. Just panning around very gently inside the tiny area where all the tiles have loaded already, is fine. No lag there.
I'm using Firefox, not Chrome. I did the equivalent thing in Firefox and there's nothing in the results any living being can make sense of. It's like a mega tetris with random colors. There are a few hundred different bits of code or procedure names plattered all over it, and that's simply impossible to compile into anything useful.
However, the latest update is about half as laggy as the current version at the time I created my first post. So something you've changed was in the right direction. It's still unbearably laggy, but there is a difference.
Here's the Firefox tetris:
And the equivalent in Chrome, quite possibly even worse than the Firefox one:
-
I was mistaken. The improved performance seems to be caused by the performance recording process. Something that that process/mechanism is doing makes the site work slightly better while capturing performance data. Now that I tried to use the site normally, the lag was just as before. So, no improvement after all.
-
@rdo118
Hi, thank you for the provided information. I had an idea of what the problem could be, and the first screenshot probably confirmed it - the readPixels function used within our forecast WebGL rendering pipeline. It is mandatory within our current pipeline, which was implemented many years ago based on WebGL1, and this approach was necessary and totally valid at that time. This function (gl.readPixels) can indeed be problematic; however, it is used with care and as little as possible. However, in case of using high-res screen(s), the performance could eventually degrade. To assure you, there were no changes in the pipeline in the last 3-4 years.We are not going to do any modifications to the old pipeline since we are already working on a new one, which does not use any of these problematic functions at all. This will take some more time, so as a temporary solution, I can advise lowering your resolution (in case you are using multiple displays or e.g., a 4 K display) or setting browser zoom to e.g. 150-200% (in Firefox it is in the hamburger menu top-right).
Thank you for your patience.
