[SFML 2] I need your help for the ATI fix

[Laurent]

Hi

The fix is finally implemented, it's a shame it took me so long because the code is really really straight-forward. Well, it involves a major design modification that I don't really like, that's why it was not implemented before. So it's not a magic fix, it's a new design that allows SFML to get rid of this bug.

But anyway. This API change adds a new class, which is in fact nothing more than sf::Context. But now it is required in the main thread as well (unless you create a render target first). And I need you to... find a name for it

I don't like sf::Context because it's not meaningful at all. It refers to an implementation detail that most users (especially beginners) won't understand. This class must be used to enable graphics calls in a thread -- so I guess its name should refer to the Initializer/Thread/Graphics words. I really have no idea, so please help me

Here is an example:

Code: [Select]

void func()
{
    sf::???? ???;

    sf::Image image;
    image.LoadFromFile("...");
    ...
}

int main()
{
    sf::??? ???;

    sf::Thread t(&func);
    t.Launch();

    sf::RenderWindow window;
    ...

    return 0;
}

After we all agree on a perfect name, I'll commit the fix, let you test, and try to boost my motivation to release SFML 2 soon. Even if it means dropping the changes I wanted to make on the drawable system.

I'll clean the task tracker as well, and *really* start to use it: I'll put there all the remaining tasks for SFML 2 (the real ones), all bugs, suggestions, etc. that were collected in my private text-file-todo-list.

[Hiura]

What about http://www.sfml-dev.org/forum/viewtopic.php?p=27685#27685 ? It comes to my mind we could also use some macro and keep everything like it is now. (Maybe I'm missing something, I hope not!)

Code: [Select]

// in SFML/Window.hpp
#define main _sfmain

// in some Main.cpp (on the SFML side)
int _sfmain(int, char**);

int main(int argc, char** argv) {

    // some stuff

    int returnCode = _sfmain(argc, argv);

    // some stuff

    return returnCode;
}

// in the user's project
#include <SFML/Window.hpp>

int main(int, char**) { /* classic stuff */ return 0; }
The only downside I see with this is that the main (in the SFML-user project) must be of the form int main(int, char**). But maybe this could be managed with some kind of trick ?

EDIT : ok, I see another side effect : how will this work with Qt ?

[Laurent]

Yeah, using a custom main is not an option. There are too many situations where you can't "control" it (plug-in, integration to an existing GUI, conflict with libraries that use the same technique, ...). And it only solves the problem for the main thread.

[Hiura]

That what I was missing.  :lol:

(I've no good idea for the name)

[devlin]

Will it be used for anything (as in called by the code)? Or is it just a static object that needs per-thread existence?

[Laurent]

It is just a static object that needs per-thread existence. It will have a constructor, a destructor, and that's it.

[Spidyy]

so I guess its name should refer to the Initializer/Thread/Graphics words. I really have no idea, so please help me  

sf::GraphicsInitializerThread.

=p

More seriously : sf::GraphicsExtend, in the way you extend the graphic functionnalities to more threads.

[Oneiros]

Hi!  (sorry for my English ^^)

sf::GraphicsRoot : because without it the rest can't stand up :p
sf::GraphicsInit     : because we have to create it first.
sf::GraphicsContext : because without context we don't see anything :p

Or just ArtworkThreadInitialiser

*run far far away...*

With only the main thread we need this one? or it's just  with more than one thread?

[zenkimoto]

Just out of curiosity Laurent, what were the custom Drawable changes?  I, for one, can wait until these changes are complete!  

Do we need to cheer you on? :lol:

[Laurent]

With only the main thread we need this one? or it's just with more than one thread?

You need it in any thread where you don't have an active render target, whether it is the main thread or a secondary one.

Just out of curiosity Laurent, what were the custom Drawable changes? I, for one, can wait until these changes are complete!

Would be too long to explain, and I don't want to pollute this topic. But you can probably find a discussion about it on this forum (I don't remember where it is, maybe it's on the french side).
The problem is that this thing is totally blocking me, so if I wait and wait and wait... SFML 2.0 will never be released.

[devlin]

If you want the name to be newbie-friendly, I would suggest you leave thread out of the name. Chances are, most will just use a single thread in their programs and be done with it. A blurb in the documentation about threading usage should be sufficient for the non-newbies. (or you could provide a typedef that gives a TLS-name for those wanting to be specific that it's for multi-threading use, since you require one per thread).

I understand why it's difficult to name it - since it's just an object that needs to exist - but not actually used for anything else.

I would probably call it something with Rendering, rather than Graphics. Or add Enabler at the end.

sf::Renderer;
sf::GraphicsEnabler;
sf::RenderingContext; (or sf::GraphicsContext works well too)

Or if you really want Thread in there:

sf::RenderingThread rt;
sf::GraphicsThread gt;

Avoid Initializer - it's darn hard to spell right.

Or if you want to appeal to newbies:

sf::GraphicsSingleton s; // and a sf::GraphicsThreadSingleton typedef.

[Mjonir]

What about a simple "sf::Init"? Or "sf::Start"? It's more like a function name than an object name, but I think it's the easiest to understand in a first tutorial

[Zinlibs]

Yes, I agree with Mjonir, Sf::(Draw?)Init is the easiest to understand solution.

[Laurent]

I'd like to keep full words, this is one of my coding rules. So we'd be back to sf::Initialize(r).

[Lokk]

What about a global function like sf::Init() ?