Just so that this discussion doesn't derail into another GitHub issue with an unmanageable number of comments:
First a bit of context:
Yes... the
symptoms of the issue were reported even before the merge, and I think we gave enough time for the reporters to provide
any sort of constructive information that would aid us in tracking down the issue. The first mention only included the information "Windows 7, runs in VM, doesn't run on the host", no mention of the GPU Vendor, driver version, or any effort what-so-ever on the part of reporter in narrowing down the search area since they are the only one with access to an environment in which the issue can be reproduced. Months went by, no other information regarding this specific issue was provided. We asked, waited, and just moved on as we would have to at some point.
Within the first week after the merge, another user reports being able to independently reproduce the issue and actually provides information that is useful to us to understand the nature of the problem. The user goes even further and suggests 2 ways to resolve the issue. Since one of them (updating a really really old driver) is in my opinion the better option for the user from a more global perspective, and I assumed that they were able to resolve the issue on their own without demanding any changes in our direction, I didn't bother to follow up on the issue, hence no comment.
3 weeks later, you also independently reproduce the same issue, with a similar environment to that of the second reporter. I would have expected that you might have took note of what they wrote since you were at some point subscribed to the PR, but I guess there might have been legitimate reasons for unsubscribing.
Now for some facts:
The reason why this only happens in certain hardware/driver configurations is due to the fact that Nvidia obviously didn't follow the
API description that Microsoft provided for wglMakeCurrent.
If hglrc is NULL, the function makes the calling thread's current rendering context no longer current, and releases the device context that is used by the rendering context. In this case, hdc is ignored.
The documentation states fairly clearly that hdc
is ignored when hglrc is NULL. This is not something that can/might be done or is implementation defined, it
is done, which is a contract that the implementation has to fulfil. Not doing so, for whatever reasons is a breach of contract and therefore irrefutably a bug. Nvidia didn't go out of their way to fix something in their OpenGL implementation that wasn't clearly broken. The fact that it is fixed in more recent drivers shows that they acknowledge that this was a bug on their side.
I looked around the internet when the issue was clearly explained and I found the following implementations:
SDLGLFWAllegroFreeGLUTBesides SDL, none of the above libraries actually work around the bug in this outdated Nvidia driver. This would mean that you can construct cases in which those libraries would also fail to function correctly. I'm fairly certain that other similar libraries not mentioned here have also chosen the route of not trying to work around the bugs of others which have long since been fixed.
Philosophy:
Because SFML can be considered a middle-ware library, there are some things on which it has to rely on. We are not here to re-invent wheels because we can or because others have done so in the past. We simply assume that everything "below" us "just works". This includes things like the operating system, drivers and dependency libraries. That is also the ascending order in which we have influence over when it comes to fixing things "upstream". If this assumption does not hold because things happen to be broken sometimes, then the only productive way to move forward is to look for the source of the problem and solve it there. Fixing it downstream leads to more projects having to build in the same workarounds and to what end? At the end of the day, the driver maintainers at Nvidia are paid to make the smallest changes that affect the largest amount of users, why should the burden rest on those who are not paid and make the smallest change? In this case, Nvidia even delivered, and it is down to the user who is always responsible for keeping their system in a usable state by updating the things which are necessary.
I am starting to understand the reason why Microsoft made updates more or less mandatory in Windows 10: Users are simply not able to understand, too lazy or selfish when it comes to being part of the software maintenance cycle. Why put up with broken software along with millions of others when all you have to do is report it as broken and wait for it to land on your system as part of a routine update? This is also the reason why OpenGL driver support was so horrible for so long. People simply "didn't care" since DirectX was an available and not-so-crippled alternative, and of course the developers always have to cater to what the users expect and are willing to understand. Khronos made the right move with Vulkan: Push more of the support responsibility towards the game developers. For some unexplainable reason, PC gamers are more comfortable with Steam updating the same game 10 times a day than with downloading a driver update once a month themselves. Why? Because it is not as fully automated.
Software, and especially libraries, should not have to make compromises and undermine their principles just because people are lazy/ignorant/selfish. As is common these days "It's a people problem".
Comparing software among each other based on how far they are willing to go in order to "stay in the club" is also not the way to go. Just as it is not the way to go in real life. Just as in real life, judging software should be based on principles, and because every software project follows another set of principles, comparing their implementations among each other is simply ignorant. The quality of the software should be judged on whether they are able to fully fulfil their goals while staying true to their principles. Whether those principles align with those of certain users will be the deciding factor when the user considers using the library in their projects. As such, people who say/threaten things like "I won't use your library unless you do things like other library X." just show how short-sighted some people have become. There is a reason why more than one library exists, and that is because there are different groups of people with different focuses. In the end, if one values over everything else having a perfectly fitting "library" that fits their purposes 100%, nobody prevents them from just implementing it themselves, even based on forks of other open-source libraries. Threatening open-source projects leads nowhere, and people should learn to understand that.
This is not directed at anybody in particular (so please do not feel offended), it's just a trend that I have noticed creep up over the last years.
The status quo:
I've already commented in
issue #1165, that more work has to be done to get the OpenGL implementation into a more stable state again. I can imagine that this might include the aforementioned workaround as well. When I have the time, I will commence work on this issue.
Just for the record: I am considering this,
not out of populism or the belief that this is a justifiable way to develop software going forward, but simply due to 2 reasons. SFML's OpenGL implementation is the only rendering implementation that is currently available, and in order to guarantee a certain degree of backwards compatibility (even in the future when other renderers might be available and OpenGL becomes a fallback), we have to take into account that certain platforms are simply no longer supported and thus that a driver update might not be available for all users. This does not endorse in any way neglecting to keep drivers up to date when they are obviously available. This will remain the primary route to fix issues when it comes to troubleshooting SFML. The second reason for considering such a workaround is simply because it requires relatively low effort and affects a file that might have to be modified any way.
And finally:
Just a remark, but in my opinion, the title of this thread can be considered a bit misleading. SFML is not "broken entirely", let alone not on all platforms/hardware. This is isolated to the sfml-window module and more specifically OpenGL context management, only using a really old driver and only on Windows. Starting a thread with such a title, furthermore in the General section, can even be considered a bit as "click bait" and conflicts with the informal netiquette that can be found throughout the forum.
Also, stating that you consider this a critical issue is an acceptable opinion, however, please bear in mind that not everybody will have the time to fully understand the implications. This is specific to a bugged driver, and only affects the most recent release of SFML. If people favour stability over being at the cutting edge, we also provide all prior versions. Nobody is forced to make use of an SFML version within the first month of its release. If an older version worked 100% for them, then there is no real reason to update. Stating that a specific version of SFML is critically broken without specifying the details upon which users can decide which version they should use just creates more uncertainty than SFML currently needs.
