Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dmfrodrigues

Pages: [1]
General / Unable to create window with antialiasing on MacOS
« on: August 26, 2021, 03:15:20 am »
Hi! I was trying to create a window using SFML with antialiasing, but it does not seem to work in MacOS. It works just fine in Windows and Linux (Ubuntu). Using anything other than antialiasingLevel=0 in MacOS causes the program to crash with message:

Error. Unable to find a suitable pixel format.
zsh: segmentation fault ./example

I'm on a VirtualBox VM with Windows host so I'm not sure if that might be the issue as MacOS can be quite annoying if not running on Apple hardware. Here are the details:

macOS Big Sur 11.0.1 (20B29)
SFML v2.5.1 (built from source code)

It might also be somehow related to these issues: https://github.com/SFML/SFML/issues/161, https://github.com/SFML/SFML/issues/1582. The thing with the second one is that the issue does not occur with a "high" value of antialiasingLevel, it happens with any value other than 0.

It's quite late over here to make a MWE, but I'll make one in the morning. In the meantime even without a MWE it'd be great if I could get some feedback on this issue, as the MWE will be as simple as creating a new window.

Graphics / Issue with RenderWindow and threads
« on: February 19, 2021, 05:55:49 pm »
Computer: Laptop, 8 cores
Environment: Ubuntu 20.04.2 LTS, 64bit, X11 windowing system
SFML: What is available in apt as of now under the name 'libsfml-dev', which is version 2.5.1+dfsg-1build1
(For any more info feel free to ask)


I was trying to create a multi-thread application, where three threads are created and each thread creates a single window and manages that window's event loop (except for the main thread which is not responsible for any windows), and then the main thread joins all additional threads and exits, so basically the application waits until all windows are closed. Here is a MWE:

#include <thread>
#include <SFML/Graphics.hpp>
#include <X11/Xlib.h>
#include <stdio.h>

void newWindow(){
    printf("Creating window\n");
    sf::RenderWindow *window = new sf::RenderWindow(sf::VideoMode(400, 400), "A window");
    printf("Created window\n");
    while (window->isOpen()){
        sf::Event event;
        while (window->pollEvent(event)){
                case sf::Event::Closed: window->close(); break;
                default: break;
    delete window;

int main(){
    std::thread t1(newWindow);
    std::thread t2(newWindow);
    std::thread t3(newWindow);
    return 0;

Real simple, actually. Compiled it with
g++ -Wall main.cpp -lsfml-graphics -lsfml-window -lsfml-system -pthread -lX11
as the law demands.

I was expecting to see three windows open up, and have the following on the console:
Creating window
Creating window
Creating window
Created window
Created window
Created window

or something along those lines, as print order might change.

However, what I get is often only three times Creating window and the app is stuck (and the threads probably aren't going away, as my CPU jumps from a stable 5% to a stable 50%).
Once I got
Creating window
Creating window
Creating window
Failed to create input context for window -- TextEntered event won't be able to return unicode
Created window

And once I closed the only open window, the app is stuck.

And when I comment out t3, I sometimes get it right but once I got
Creating window
Creating window
malloc(): smallbin double linked list corrupted
Aborted (core dumped)

In this case it exited with an error.

How come the application gets stuck? I truly hope this is not some sort of rookie mistake, I've looked through the forum and the docs for a whole day and couldn't find the issue. From the console prints I can say that the issue is likely in the RenderWindow constructor.

Any input is appretiated


Added a global mutex that I lock before constructing RenderWindow, and unlock after constructing RenderWindow, and so far the issue has not surfaced. I wonder if there's some simultaneous access issue that RenderWindow is not handling (like asking X11 to create a new window or something like that)

Pages: [1]