[PATCH 1/8] Revert "wined3d: Track if a context's private hdc has had its pixel format set, so we don't need to check it."
ken at codeweavers.com
Mon Nov 2 15:46:50 CST 2015
On Nov 2, 2015, at 3:12 PM, Henri Verbeet <hverbeet at gmail.com> wrote:
> On 2 November 2015 at 21:37, Ken Thomases <ken at codeweavers.com> wrote:
>> This reverts commit f3aa4812382caa459b9b612f66998c6ea8257594.
> I may have mentioned this the last time this series came up, but if
> you want me to consider signing off on this it wouldn't hurt to
> include some text on what the actual issue is, what configurations are
> affected, why a year and a half isn't enough time to fix it, etc.
I didn't get any feedback on these reverts last time until I asked and then was simply told that you and Alexandre had discussed it and felt that the original change being reverted was "correct" even if it had undesirable side effects.
I'm resubmitting now because Alexandre asked me to for the 1.8 release.
Patch 5 cites the bugs that are actually fixed by that specific revert. Patches 1-4 are just removing things which didn't break anything but only make sense on top of the restore-pixel-format commit.
I'm not sure what you mean by "what configurations are affected". It's not so much configurations (although it primarily affects the X11 driver), it's certain apps and their D3D/WGL usage patterns. As the pixel format is changed back and forth, the window has to be torn down and recreated constantly because the visual has to match between the window and the GL context. This causes flickering and probably loss of X events.
As to why a year and a half isn't enough time to fix it: when velocity is 0, distance traveled is going to be 0 regardless of time. I'm no longer working on the proper fix. Let's chalk it up to emotional immaturity on my part. If that makes you reluctant to have my work in wined3d, then you have a sticky dilemma to resolve. ;)
More information about the wine-devel