Yup I did. I'm not at all doubting that some IPS panels have retention issues (there are photos online) and I find it entirely plausible that flicker may accentuate it. That may be what the burn in in God of War is.

Persistent flicker is more interesting. That seems to be a thing too, I'm just not sure GoW's was that, since it seems like there were so many people for whom it was instantly fixed with a settings change.
Yea. It's a bit hard to discuss since there may be more than one problem involved, but the majority of the reports hint at a firmware bug, plain and simple. As does the link posted by sanscript above. Anyway, as I said before, I'm not entirely ruling out a physical phenomenon that is masked by the change in drive characteristics when VRR is turned off or refresh rate changed. 2x, 75Hz. My monitor goes to 144Hz but not with the resolution I'm currently running, unfortunately.

So far this is the most interesting technical bit I've found on the topic: http://forum.arcadecontrols.com/index.php?topic=159255.0

"The separate phases (positive, negative -- even/odd numbered refresh cycles) of inversion essentially have independent image retention, so that's why you see flickering after you exit the game -- one inversion phase is burnt-in with bright images and the other inversion phase is burnt-in with dark images."

Come to think of it, I think I have seen subtle flicker on some panel, and never thought much of it. I just can't remember which one. I'd assume it's my previous panel but that was VA.. maybe retention isn't really specific to IPS?

So I finally realized what the remaining piece to the puzzle is. I intentionlly say realized as it's no other resource that I would find it's just that the answer has always been right in front of my eyes, but I could not see it. Well, a bit of thinking when one cannot sleep...

The asnwer is right in what pixel inversion is all about. For those unfamiliar with what it really means (based on the answers throughout the thread probably majority of the audience)... every pixel, or better say RGB subpixel on an LCD screen needs to receive current to display what it is required to display. However, the current causes the pixel to deteriorate and maintain its state, most panels would totally fail and have a picture burned into them within minutes or hours if the same polarity was applied to the pixels. That's why pixel inversion exists, it reverses polarity with every frame, simply put: one frame is +-, the other is -+. Problem solved. However it does not go without associated issues: the reverse polarities do not always have the same voltage, that's why some (many?) screens just flicker by default. Depends on how close the two voltages are and how sensitive people are to flicker. Such screens are then flickering at a frequency that is half the set refresh rate. Of course manufactures spread the application of reversing polarities in certain patterns, they do not reverse the whole screen in order to make it less visible to human eye, but if the voltages' difference is large enough, the fliker will be seen.

Now, let's get back to our original problem with a flickering image sent to the screen. Imagine a picture that would display all white screen in one frame and all black in another: what would the result be? Very similar to a screen that does not have the pixel inversion properly handled: as, say, every odd frame would be basically without any picture (black) and all even with full white, only one polarity would be used while the other left suppressed. Then inevitable must come: depending on screen's sensitivity to burn-ins that obviously depends on given technology (IPS vs. TN vs. VA and their sub-technolgies) the screen will start to flicker continuously or burn in the image to the screen. Until the spent pixels will start to regenerate. Real life standard image is either stable or offers a wide variety of changes to each subpixel therefore these issues do not appear under typical monitor usage.

So the bottom line is that EVERY LCD screen will eventually suffer from a flickering image if it has the right frequency and is "properly" synchornized with refresh rate. If it is not then the white vs. black may switch between polarities from time to time and the effect will on average compensate itself. Of course white and black images are extreme cases, but any flickering has that potential, the impact will only be smaller if it's not pure white vs. black.

For me this concludes the whole thing and I will probably not be able to get any more info on this. "The circle is complete": I can see the Simon 25th flicker, I found what may be the probable cause (the opengl overlay) and why it can impact screen even outside of the game. In my view the devs should fix it and Steam and GOG should create pressure on them to do so. But of course let's see how it goes, given GOG's answer I wouldn't hold my breath.

It definitely makes no sense to contact Lenovo, the observed effect is a natural part and a weak point of the LCD technology.

-------
And one extra comment: there was a question from Clarry whether I speak of flickering or burn in. Actually both. From what I could gather, the two different polarities wear off pixels separately so the pixel could be spent in one direction while the other direction is OK.

Therefore permanent screen flickering is basically a "one polarity direction" burn-in (that's why it flickers - and it does so with half of the screen refresh rate), while real visible "stable" burn-in that a human eye can see is a burn-in for both polarities. Real full burn-in can also be produced if the screen is exposed to a flickering image of the right frequency and sync with refresh rate: imagine the screen is exposed to stress in one polarity for several minutes, develops a one direction burn-in causing flickering... and the sync suddenly changes with the other polarity so the other direction is now impacted in the same way after a few mins. You get a full stable burn-in.

I mostly agree with this conclusion. Thank you for persisting and not giving up because of all the doubters who were not willing to engage with an open mind.

However, I'm still not sure whether I agree with the conclusion that the game (solely) is to blame and that the hardware is blameless, or that every LCD screen suffers from this.

At least my understanding is that there are screens that do not suffer from the adverse effects. I can't confirm it, but if we think about it for a moment..

It's important that the average voltage of a cell stays zero over time. There ought to be more than one way to achieve this. One particular way would be to invert polarity every refresh cycle and optimistically hope that the input signal doesn't change in sync with refresh. But it doesn't seem implausible to use different patterns; one simple possibility would be an extra inversion during refresh cycle (so inversions are at 2*HZ). That might not look good, but other more feasible patterns could involve less than one inversion per cycle, possibly a random number of inversions. In digital electronics there are various patterns commonly used in self-clocking signals to ensure there is a transition every so often (clock recovery would fail if the line held a constant voltage for too long, plus some signals are capacitively coupled and won't pass DC so transitions are absolutely required).

I don't know how feasible those techniques are to apply to a panel. Topic for further study. It's possible that this is a solve-able problem (and perhaps some panels even solved it) but panel manufacturers are also not too concerned about it (race to the bottom, why solve a problem if you can cut corners and most people are not affected by it and you can blame the computer/game anyway?). It should require more logic gates at least (you can't pull a random pattern out of nowhere, and if you're tracking past state like in self-clocking signals, you'd have to do that for every pixel), which suggests that solving it is not free.

If it's possible to handle this in the panel controller, then IMO they should. I still think that no pixel data should damage the screen.

But yeah it doesn't really make sense to contact Lenovo, now that we understand the mechanism.

Well, I admitted myself above I could not see the effect on other screens, but not that I would try it on many and for longer periods of time (and none of them were IPS). Interestingly I have one more Lenovo laptop of the same lineup and the very same graphics card and an IPS screen :) But for obvious reasons I am not willing to risk anything, to have two laptops with this burn in is not something I would be seeking.

Additionally, as I also mention above, the effect is not overly big and some people I showed it to even could not see it. Which may be another reason why there's been no complaints on the game so far.

There are also many aspects that come into play: panel type, control electronics, firmware, etc. As stated on multiple occasions above many Internet sources agree that IPS screens have the biggest issues here, with burn-ins overall. As for electronics what matters is that not all monitors necesarily must be running in pure "what you send is what you get" mode. Most modern monitors further process the image which increases chances of de-sync of flickering with refresh rate. If the de-sync switches fast enough you can't get a burn in. That also perfectly explains why people with Ragnarok were better off with their TV's game mode disabled - this means all the TV processing was in effect that probably produced a totally different image than what a 1:1 projection of what is exactly sent would.

As for the blame, I understand what you mean and can't say I totally disagree. But I have to insist that a fast flickering image is not the usual output you should be getting. If I should give an example that comes on mind - it's similar to a situation where someone steps into a highway, some cars are able to stop in time, some not. Is it a fault of the manufacturer of the car that crashed that its brakes were not powerful enough? Maybe. They should/could have done better. Or are people suddenly stepping into a highway full of cars something that is out of the ordinary and is not entirely expected?

And after all, a flickering image is not something human eyes should be looking at anyway, don't you agree?

It's not usual output but it still seems wrong to design it so that the input can break the device. Sorry I think analogies tend to break down too easily and thus don't really want to engage them, but someone stepping in a highway is not an input designed to be fed into the car. Someone pressing the brake pedal is. If the car's brake pedal breaks because you press it too hard or pump it on and off rapidly, yes, the car is misdesigned and should be done better. It should be designed to withstand the human forces applied to it. You can argue that someone stomping on the brake with all their might is not a usual input, but the car should still be designed to withstand it.

There are more interesting analogies e.g. with springs and suspension -- could a certain rhythmic pattern of accelerating or braking cause such intense bouncing that the car becomes uncontrollable? In fact, it has happened in the past. Modern shocks are a lifesaver. Could it still be possible to upset the suspension with the right pattern? Are we up against laws of physics that can only be managed to a limit? I don't know really.

But it it's fixable within reason, like all modern cars have mostly fixed suspension instability of yore, then it should be fixed rather than blaming the problems on unusual road, unusual driver, unusual whatsoever. Likewise, if a panel can within reason be fixed to more or less never suffer this problem we're discussing, then I think it should be fixed.

Obviously I'm not an expert on the subject matter so I can't say whether the fixes are feasible, but it doesn't seem impossible. Remember how older LCDs would only have, say, six bits of depth per color component? These would also use a random dither pattern to mask banding. There are screens where you can see the dither noise with naked eye. So it seems entirely plausible that a random pattern could likewise be applied to polarity inversion, effectively fixing the problem (unless someone goes out of their way to reverse-engineer the screen and replicate the pattern in software, but at that point we're talking about deliberate damage which I'm less inclined to worry about). Shrug. Never caused any adverse effects for me. I kinda enjoy whacky effects in fact. And I've certainly thought about implementing transparency in a game by flickering overlapping objects -- temporal mixing rather than spatial mixing. Too bad the results differ too much depending on monitor.

Agree, analogies are always just approximations and the one I used might not have been the best one.

But as for the fix not sure what you suggest could really be applied to panels, at least not easily, but of course I am in no position to judge that, we'd really need a video panel engineer here now.

On the contrary if you think about it a fix is relatively simple: run the monitor internally at twice the refresh rate than what the monitor reports to the graphics card (meaning every frame is displayed twice). But when manufacturers are able to achieve higher refresh rates it of course sells the product better to offer this higher refresh rate to users rather than use it to protect the panel from issues that are rare and should not be happening.

EDIT: Just had some time to read your recent posts again and I see now that you are mentioning the 2x refresh option too as a possible solution. You call it pixel inversion in between cycles. However, pixel inversion is, by definition, a cycle in itself, therefore running at a double refresh rate is the only option here. And when you are capable of increasing the speed of your panel, I bet that marketing dictates you use it for something more visible than some hidden protection.

And I do not need to remember when LCDs used to have 6bits only. Many cheap laptop screens are still on 6bits even today. And it does not matter that much, many big monitors have 6bits too (especially TNs) and the extra bits are added by something called FRC (which in essence is nothing more than a form of temporal dithering) so that externally they report as 8bit while they are actually just 6+2. FRC is used in most 10 or 12 bit panels as well where natively the panel is two bits less (8+2 or 10+2).