Since the most recent Windy.com update a few days ago, the map is extremely laggy. I'm on a very, very high-end computer, and yet it can take a second or two for the map to update after zooming a step or advancing the forecast time one step. Simply intolerable and practically unusable. This is using Firefox, the latest version (141). Chrome (also latest version) has the same issue, although it manifests itself slightly differently, with an initial lag and then a fast load, lag again, then fast load, and so on. Both worked perfectly fine, fast and smooth, before the recent update.
Nothing else has changed on my system in that time, and everything else, everywhere else, works just as fine as before, so this is very clearly a windy.com issue.

@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.

@Suty said in Map is extremely laggy since the latest update:

@rdo118 Could you please tell us what versions have this issue in Windy? Do we talk about all of them or only radar or other layers?

What versions? This is the web version, running in browsers. What your internal version of that is, I don't know.

All layers are affected, but the weather radar layer stands out as not that laggy (it's not one I normally use - my main layers are wind, thunderstorm risk and rain/thunder). It's not good, and not normal, but if all other layers are 10 on lagginess scale, then weather radar is maybe a 2 or 3.

@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.

@schilpat said in Please restore compatible graphics mode:

@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.

Got the new test version today and it seems fine. The main map layers load quickly and almost perfectly smooth. It's really only the text layer (place names) that is a tiny bit slow, but that's not a real issue for me. Still much, much faster than before.

@Threlfa7 Yes, I see something like that as well. It feels like the wind arrows show the correct values and directions, but the model data in the table below is shifted along the timeline.

Strangely, it looks fine now, for me.

I'm seeing the same thing since the last update. There seems to be absolutely no relationship between the numbers and directions shown for the wind arrows on the map at a given time and the wind values in the comparison table. Here's a screenshot for time 20.00. I've scribbled the model names for the table rows in red.

@Gkikas-LGPZ Ah ok, found that.

Sure, I could remove a forecast model in that view, but that's irrelevant. I only use the location forecast for wind, the one in my screenshot. The stupid AI model remains there even if I've removed it from that full-screen in the compare forecasts view (which is a terrible way to view forecasts!).

@Gkikas-LGPZ I can't find any link or button named "Source", nor anything else that brings up a "compare forecasts" function. The view in idefix's screenshots is something I've never even seen. Windy doesn't look like that for me.

This is what my interface looks like. Where is the "source" button?

@idefix37 That is quite simply not the way it looks for me. Here's a screenshot of the location wind forecast. I can't find any way of enabling/disabling individual forecast models.

@Suty After my comment, I noticed that the ICON-D2 row switches over to ICON-EU when the D2 forecast runs out. I suppose that's a decent solution for the longer forecasts.

But having more concurrent forecasts helps in forming a picture of what the wind situation is likely to be in the next half day to a day.

ICON-EU probably has the most reliable wind forecast for my location past the short forecast window of the higher-resolution models available. But since the latest update (the one with the yucky AI crap), ICON-EU is no longer in the location wind forecast. It's still available as a model for the main map mode, but that's not useful for localized wind.

If there's a lack of space, get rid of the stupid "meteoblue ai" bullshit. Meteoblue has never been even close to accurate or reliable for my area, so it's a complete waste of space.

I use Windy mainly for wind forecasts to determine whether the wind is within my limits (low and high) for going sailing. Sea breeze is a very prominent source of wind where I live, but the forecast models that use large cell sizes usually fail to forecast sea breeze completely, or vastly underestimate the wind speeds (the forecast for tomorrow shows 5-6 m/s for the bad models and 9-10 m/s for the good models, which is a huge difference for my sailing). Sea breeze is such a small-scale phenomenon that it just doesn't show up at larger model scales. It's about 10-15 km deep here, and that just won't show if the model uses 20+ km cells...

When I look at the wind forecast for a location, I get a stack of seven different models. Usually, I'm only interested in two or three, and never the default one that's used for the overlay (ECMWF, mostly waaay off). Even worse is the gaggle of wind arrows on the map, where all models are shown.
It would be awesome to have the ability to completely remove the models that never show realistic winds from ever showing up in the stack and on the map.

@schilpat said in Please restore compatible graphics mode:

@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.

Got the new test version today and it seems fine. The main map layers load quickly and almost perfectly smooth. It's really only the text layer (place names) that is a tiny bit slow, but that's not a real issue for me. Still much, much faster than before.