Posts made by schilpat

@AlanTheBeast Hi, we already discussed with colleagues about this topic (whether to extrapolate when smooth animation is turned off). Both approaches make sense in their way, but in the end, we'll probably implement it in the future :)

@AlanTheBeast Hi, the reason why the futurecast is not working for you is because of Smooth radar and satellite animation setting is turned off (you can change this in settings). The current implementation does not support extrapolation when smooth animation is turned off.

@AlanTheBeast
Hi, thank you for the report. Could you answer us a few questions on that?

• Does it happen every time you open the radar overlay?
• Does it also happen in the satellite overlay (either with radar data (you need to enable it via overlay with radar) or even with satellite data)
• What MacOS and Safari versions are you using?
• Could you send us a short video, where you drag the timebox from past to future, so we can see, what actually happens?

Thank you very much!

@MetalAnon Hi, since the error appeared after updating the iOS version, and the version 18.7.2 (RC) is not a stable version, there is a high chance that something related to WebGL got messed up by Apple in that version. We cannot do much about it :/ We always recommend using stable OS versions to prevent these problems.

@MetalAnon
Hi, could you tell us what iOS version and what Apple device you are using? Does the error happen every time you open radar layer? Does it also happen on the satellite layer?

Thank you!

Hi @jmjm26, since Q3 2025, we have been using a new renderer for satellite overlay. We'll try our best to mitigate this issue. Thank you for your patience.

@jmjm26
Hi, thank you for the report. Could you tell us what device and system version you are using?

We are working on a solution that might resolve the problem. However, there are combinations of some types of devices (specifically low-end) and OS/SW that might struggle in computationally intensive tasks, in this case, during satellite animation.

As a workaround, I suggest stopping the animation before moving with the map.

Thank you!

@stkosel
Hi, this is a bug. Could you try some other browser, e.g. Google Chrome, since the issue could be caused by the new Firefox version. Thanks!

@smyru
Hi, since the update v47.0.0, all layers are webgl-only. Based on the information you provided, there must still be some flag that prevents usage of WebGL within your browser. All layers can run on both WebGL1 and WebGL2. Please, make sure that flags webgl.disabled and webgl.disable-wgl are set to false (in case of about:config in Firefox), and double check other flags that may block WebGL.

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

@richlafferty
Hi, thank you for troubleshooting the issue and finding its cause. On our end, we currently cannot reproduce the issue even after modifying the FF config. To help us resolve the issue, could you answer the following questions?

• what version of Firefox and OS are you using
• since when do you experience the mentioned problems (e.g., since the last Windy update - unlikely, FF update, etc.)
• did you perform any changes in the config prior to the rendering problems - e.g. the mentioned color space adjustments
  • alternatively, whether you have a display that supports p3 color space
• in case you are still able to "corrupt" your profile, could you test whether satellite overlay has any rendering artefacts (using the corrupted profile)

It is highly possible that it could be caused by the mentioned color space conversion during the image decoding phase (we already had a similar issue on iOS last year, which caused artefacts on radar+ layer). Thank you for your cooperation!

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

@Avjaco

Hi, thanks for the report. Could you provide us with more information to help us track down the problem?

• were you using Graphics compatibility mode before the last update?
• does it happen on other layers (or layers with some patterns - e.g. rain & thunder)?
• what device and browser version are you using?

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

Hi, regarding the performance issues, could you please check the following post?
https://community.windy.com/post/217606
Thank you

Hi, regarding the performance issues, could you please check the following post?
https://community.windy.com/post/217606
Thank you

Hi, we are sorry to hear that you have performance issues without the graphics compatibility mode. We are constantly trying to optimize the app's performance and size, which also involves removing old and deprecated functionality. One of these is graphics compatibility mode, which was introduced many years ago when WebGL (one of our main technologies) did not have that great support among devices and browsers as it does nowadays. Recently, since there was a very small number of users actively using it, we decided to discontinue it because it took quite a significant part of our codebase. Another reason might be that we already have a few WebGL-only layers (radar, satellite, radar+) and that we are trying to incorporate WebGL (gpu rendering) into Windy as much as possible.

However, we would like to dig into the issue and try to solve it or find its source, and ideally help you. For that, we need additional information about your device, without which there is not much we can do. So, if you mind, would you try the following steps and report to us?

• Check that graphics acceleration is enabled in your system (if disabled, it might be emulated by your CPU, which might cause the problems)
• Check that you are not running power-saving mode
• GPU dump
  • go to chrome://gpu/ in chrome
  • or go to about:support#graphics in firefox
  • just paste the link into your browser and send us the report in the response
• Browser dump
  • go to chrome://version/ and send us google chrome version, user agent, os in the response
• Try some webgl sample/benchmark and check, whether the performance issues persist
  • e.g. https://webglsamples.org/aquarium/aquarium.html
  • or at least https://get.webgl.org/

The issue seems very suspicious since Windy behaves relatively smoothly even on low-end and old devices...

Hi @alanduckers,

the Radar+, Radar, and Satellite layers use the same data. The difference is that Radar+ also performs the mentioned extrapolation of past satellite data. However, this extrapolation does not apply to radar data in the Radar+ due to technical constraints. As a result, and because radar providers can experience delays, you may notice that radar and satellite data do not always sync correctly in the Radar+ layer. For example, in the UK, the radar data currently lacks the most recent timestamp. Regarding the strange patterns, these might be caused by satellite data outages that are compensated for through extrapolation.

Hi, this is because of Radar+ satellite image is extrapolated even in past to ensure smooth transition between the last available frame (which can be 25 minutes old) and the nowcast (red part of the timeline).

Hi, we are aware of the issue and have fixed it; it should be resolved in the next version. The problem was caused by a bug in the iOS 18 beta. We advise using stable OS versions.