Instead of cloning the window to create dummyHWNDs and dummyHDCs to avoid calling the SetPixelFormat more than once in the same window, use the original window and HDC and do not call the SetPixelFormat again.
In addition to avoiding a lot of unnecessary calls, it simplifies the code and makes it match the others OS
This removes a bunch of code that is no longer needed, and running
"make update" will now automatically download the new libraries.
Differential Revision: https://developer.blender.org/D2861
It has been deprecated since at least macOS 10.9 and fully removed in 10.12.
I am unsure if we should remove it only in 2.8. But you cannot build blender with it supported when using a modern xcode version anyway so I would tend towards just removing it also for 2.79 if that ever happens.
Reviewers: mont29, dfelinto, juicyfruit, brecht
Reviewed By: mont29, brecht
Subscribers: Blendify, brecht
Maniphest Tasks: T52807
Differential Revision: https://developer.blender.org/D2333
Change the implementation so it no longer takes over the mouse cursor motion
from the OS, instead only move it when warping, similar to Windows and X11.
Probably the reason it was not done this way originally is that you then get
a 500ms delay after warping, but we can use a trick to avoid that and get much
smoother mouse motion than before.
Unfortunately this means disabling the code that ensures the title
bar is properly scaled with DPI, however better to have that as a
cosmetic issue than Blender being unusable with a lot of Intel GPUs.
Now computers that support OpenGl3.3 (but not 4.5) can run Blender 2.8.
For any given HDC, you may only call SetPixelFormat *ONCE* any future
calls for the same HDC will fail. And computers that would support only
OpenGL 3.3 wouldn't have a change to get a valid OpenGL context because
the pixelformat was already set while trying to probe the supported
contexts.
We fix this by splitting the final context creation from the query of
supported OpenGL versions.
Patch by Ray Molenkamp (bzzt_ploink/LazyDodo) with code style fixes and
comments by me.
Follow up to 9f044cb422
These comments described the difference between Microsoft & MinGW's struct definition. Now that we dropped MinGW we don't need to go into these details.
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
We only keep this as a way to get GPU_stubs to run, in case we want to do a
throughout cleanup in the codebase and want code using legacy calls to
fail to build.
There was a bug in older GLEW version which kept glGenVertexArrays as NULL
when 3.2 core context is requested [1].
Didn't find a way to check GLEW version from CMake, it seems the version
is not really exposed to the header.
[1] https://sourceforge.net/p/glew/bugs/124/
Compatibility profile was working fine, this is mostly to get the highest GL core profile version available.
Our minimum requirement is 3.3 core profile. When we request a specific GL version:
- AMD and Intel give us exactly this version
- NVIDIA gives at least this version <-- desired behavior
so we ask for 4.5, 4.4 ... 3.3 in descending order to get the best version on the user's system.
Accept OpenGL 3.0 on Mesa instead of 3.3+ compatibility profile. (requested by @LazyDodo) This will be removed after we finish moving to core profile.
Part of T49012 and T51164
MX (Multiple conteXt) support was dropped from the GLEW 2.0 library to make core profile support cleaner.
Our WITH_GLEW_MX build option was OFF by default already; this commit removes the inactive code paths.
I'm working on a plan for multiple GPUs, contexts, resource sharing, etc. This commit gives us a cleaner starting point for that upcoming work.
Tested on Mac, will test on Linux & Windows immediately after pushing.
This was blocking core context setup on Mac, since accumulation buffers are obsolete. With this (and appropriate CMake options) I now get
renderer: 'Intel HD Graphics 4000 OpenGL Engine'
vendor: 'Intel Inc.'
version: '4.1 INTEL-10.24.45'
in system-info.txt intead of
version: '2.1 INTEL-10.24.45'
For Windows 8.1 and X11 (Linux, BSD) now use the DPI specified by the operating
system, which previously only worked on macOS. For Windows this is handled per
monitor, for X11 this is based on Xft.dpi or xrandr --dpi. This should result
in appropriate font and button sizes by default in most cases.
The UI has been simplified to a single UI Scale factor relative to the automatic
DPI, instead of two DPI and Virtual Pixel Size settings. There is forward and
backwards compatibility for existing user preferences.
Reviewed By: brecht, LazyDodo
Differential Revision: https://developer.blender.org/D2539
Minimum target is still 3.3
On AMD pro driver, asking for a 3.3 context gives us *exactly* 3.3, not 3.3+ as desired.
Have not tested proprietary NV or Intel drivers, but this fix should work on all vendors.
