GUI toolkits such as wxWidgets and Qt provide their own NSAutoreleasePool
objects. To avoid pool corruption, it is required that the pools be nested,
which the previous implementation did not guarantee. Furthermore, autorelease
pools should always be drained in the same context (function, loop, etc.) that
they are created, which was not the case with the previous implementation
(https://developer.apple.com/documentation/foundation/nsautoreleasepool).
This commit removes long-lived autorelease pools, and instead each function that
calls into the Cocoa API creates its own autorelease pool (using the new C++
AutoreleasePool wrapper object).
Should fix crashes in issue #1549 and similar.
This fixes wrong rendering for RenderTexture that need sRGB encoding along a
non-sRGB window.
We cannot simply always enable GL_FRAMEBUFFER_SRGB because some drivers
enable sRGB encoding on non-sRGB window surfaces.
Also add a isSrgb() method to tell if a RenderTarget is encoding into
sRGB color space.
When the sf::ContextSettings asks for an sRGB capable buffer, set the
rendered image to sRGB mode and convert pixels when drawing.
This is the choice of simplicity compared to actually support textures
with more color depth.
- On Windows you can use Clang with both MSVC and MinGW
- When using Clang with MSVC all the MSVC conditions should be fulfilled
- When using Clang with MinGW all the MSVC steps should not be run
When waiting for an event, rather then polling, the android
looper prevents the creation of a OpenGL context till ALooper
receives an event rather then allowing creation at the appropriate time
sf::Context::getActiveContext could return an inactive context if
RenderTargets activation occured since the last sf::Context activation.
This is not what its documentation suggest, and was clearly an
unexpected behaviour.
This fix make the function return NULL if the current active context is
not managed by sf::Context (e.g. because it is a RenderTarget).
Windows uses a mechanism known as 'resource files' which provides, among
other things, metadata to a given executable/dll/driver/etc, and add a
layer of polish to a project which it would otherwise lack.
The existing dependencies in the extlibs directory
have been updated to use universal frameworks
for both x86_64 and arm64, allowing SFML to built
natively on the new M1 chipset
When a single GitHub Action build fails, the other builds should not be
canceled, but instead should continue to build.
Since the matrix is setup on OS level, a failing build on one OS usually
doesn't mean it's broken for all OS.
