Messages

1

Window / [SFML2] Missing call to XInitThreads?

« on: September 09, 2010, 10:15:45 am »

Thanks for your answer, I'll see want I can do without it.

2

Window / SFML 2: "Failed to activate the window's context"

« on: September 03, 2010, 11:58:44 pm »

Sorry for the delay. In case you plan to fix this, here is the code:

Code: [Select]

#include <iostream>
#include <SFML/Window.hpp>
#include <X11/Xlib.h>

sf::Mutex mutex;

class EventLoopThread  : public sf::Thread
{
public:
  EventLoopThread(sf::Window* w)
    : win_(w)
  {
  }

private:
  void Run()
  {
    sf::Context context;
    sf::Event event;
    while (true)
    {
      mutex.Lock();
      std::cout << "[thread 1] display start" << std::endl;
      win_->SetActive(true);
      win_->Display();
      win_->SetActive(false);
      std::cout << "[thread 1] display end" << std::endl;

      mutex.Unlock();
    }
  }

  sf::Window* win_;
};

int main()
{
 sf::Window window(sf::VideoMode(100, 100), "SFML window");
 EventLoopThread th(&window);

 th.Launch();

 while (window.IsOpened())
 {
   mutex.Lock();

   std::cout << "[thread 0] display start" << std::endl;
   window.SetActive(true);
   window.Display();
   window.SetActive(false);
   std::cout << "[thread 0] display end" << std::endl;

   mutex.Unlock();


 }

}


3

Window / [SFML2] Missing call to XInitThreads?

« on: September 03, 2010, 08:59:00 pm »

I got a problem using a thread to handle window events, and drawing in
the main thread. I'm using SFML2 (rev 1562) on linux.

The following piece of code reproduce the problem.
It lead to something like a deadlock on my computer.

The x11 doc say:

The XInitThreads function initializes Xlib support for concurrent threads. This function must
be the first Xlib function a multi-threaded program calls, and it must complete before any other
Xlib call is made. This function returns a nonzero status if initialization was successful; other-
wise, it returns zero. On systems that do not support threads, this function always returns zero.
It is only necessary to call this function if multiple threads might use Xlib concurrently. If all
calls to Xlib functions are protected by some other access mechanism (for example, a mutual
exclusion lock in a toolkit or through explicit client programming), Xlib thread initialization is
not required. It is recommended that single-threaded programs not call this function.

Adding this call solve my problem, but it could be nice to handle it
inside SFML.

Code: [Select]


#include <iostream>
#include <SFML/Window.hpp>
#include <X11/Xlib.h>

class EventLoopThread  : public sf::Thread
{
public:
  EventLoopThread(sf::Window* w)
    : win_(w)
  {
  }

private:
  void Run()
  {
    sf::Event event;
    while (true)
    {
            win_->WaitEvent(event);
    }
  }

  sf::Window* win_;
};

int main()
{
 //XInitThreads(); // Deadlock without this call
 // Declare and create a new window
 sf::Window window(sf::VideoMode(100, 100), "SFML window");
 EventLoopThread th(&window);

 th.Launch();

 // Activate the window for OpenGL rendering
 window.SetActive();

 unsigned f = 0;
 // The main loop - ends as soon as the window is closed
 while (window.IsOpened())
 {

    // OpenGL drawing commands go here...

   std::cout << f << " display start" << std::endl;

    // End the current frame and display its contents on screen
    window.Display();

    std::cout << "display end" << std::endl;
    f++;
 }
}


4

Window / SFML 2: "Failed to activate the window's context"

« on: August 08, 2010, 08:25:20 pm »

It's not a problem, it's how SFML 2 work. You have to create an OpenGL context in threads other than the main one if no window is active. That's why the sf::Context class exists.

My problem is that there is no thread (even the main one) that do not call window::SetActive. The two threads share the same context and use it.
I guess this design is not compatible with the library.


here is an example:

window is an sf::Window and global to the 2 thread.

Thread 1

t = 1 | window creation
t = 2 | window->SetActive(true);
t = 3 | opengl calls..
t = 4 | opengl calls..
t = 5 | window->SetActive(false);
t = 6 | some non graphic stuffs...
t = 7 | some non graphic stuffs...
t = 8 | some non graphic stuffs...
t = 9 | some non graphic stuffs...
t = 10| window->SetActive(true); with no dummy context in thread 2, this fails too.
t = 11| opengl calls..


Thread 2
t = 1 | need a dummy  context here.
t = 2 | some non graphic stuffs...  
t = 3 | some non graphic stuffs...  
t = 4 | some non graphic stuffs...  
t = 5 | some non graphic stuffs...  
t = 6 | window->SetActive(true);
t = 7 | opengl calls..
t = 8 | opengl calls..
t = 9 | window->SetActive(false); with no dummy context this fails
t = 10| some non graphic stuffs...
t = 11| some non graphic stuffs...

5

Window / SFML 2: "Failed to activate the window's context"

« on: August 08, 2010, 04:00:07 pm »

I got the same problem this morning, I solved it by creating a useless context in the thread. (SFML2 on linux rev 1545)

I guess this is due to this function:

Code: [Select]


bool GlContext::SetActive(bool active)
{
    if (active)
    {
        // Activate the context
        if (MakeCurrent())
        {
            // If this is the first context to be activated on this thread, make
            // it the reference context for the whole thread
            if (!threadContext)
                threadContext = this;

            return true;
        }
    }
    else
    {
        // Deactivate the context
        if (threadContext && (threadContext != this))
        {
            // To deactivate the context, we actually activate another one
            // so that we make sure that there is always an active context
            // for subsequent graphics operations
            return threadContext->SetActive(true);
        }
    }

    // If we got there then something failed
    return false;
}


Is there any other solution than creating a useless context (and make my application start slower)?

6

Window / Expose events, grabbing input and window captions

« on: August 08, 2010, 03:11:25 pm »

SFML is made for real-time applications that are refreshed contiuously, I can't find how this kind of event would be used in this context. But I'm sure you have a good example to tell me

I choose SFML2 to build a library because it is nice to use in C++, but I didn't know that is was not made for application that do not refresh continuously.
Sometimes in my library, I need to freeze the display, so I start a thread that listen to resize and focus events and redraw the content of the frozen window when necessary.
At this time, my quick and dirty fix was  to catch Expose events and push them in the SFML queue as GainedFocus in WindowImplX11::ProcessEvent:

Code: [Select]


        // Expose
        case Expose :
        {
            Event event;
            event.Type = Event::GainedFocus;
            PushEvent(event);
            break;
        }


I also added ExposureMask to the eventMask variable to receive exposure events from X11.

It works fine in my case, but I know this is a dirty fix...