Automatic batching in sfml2 branch

[Laurent]

Hi

After several weeks of work, I've finally commited the automatic batching code in the sfml2 branch.

Basically, it doesn't break anything in the public API so that most people won't notice anything except potentially improved performances.

The only modifications are on sf::Drawable and sf::RenderWindow:
- the Drawable::Render function now use a render queue instead of direct OpenGL calls
- drawables rendering nested drawables work better: the color is now combined in addition to transformations
- PreserveOpenGLStates doesn't exist anymore, states are now preserved by default (the rendering happens in one call, so doing it doesn't impact performances anymore)
- there's a new Flush function to manually trigger the actual rendering, for example if you need to draw 3D OpenGL on top of what SFML has drawn so far (otherwise rendering is automatically done in Display())
- RenderImage must now call Display() like RenderWindow
- windows are no longer active by default
- multithreading is potentially easier, as all the OpenGL calls happen in a single function (I haven't looked into that yet)
- rendering is now pixel perfect, all artifacts are gone (hopefully )

Regarding the performances, I don't really know if it will really be faster on every computer (the code now uses a little more CPU), so I'll need as much feedback as possible
This is the first version, so I'll probably have to adjust/fix a few things.

On my computer, the worst case (drawing sprites with different states) gave the same performances as before, and the best case (all sprites use the same image and states) gave a 300% improvement. Shapes gave a 500% improvement. Strings are slightly slower to render, but it's much more consistent than before; and they will soon be rewritten so it doesn't really matters
The most important is that one can now draw intensive stuff like particle systems, tiles, GUI, etc. with SFML, there's no need to use OpenGL to get decent performances.

The next step will now be to rewrite PostFx to be compatible with the new system (and apply the modifications planned in the task list).

Please note that the quality of text rendering is slightly worse than before, it's a work in progress and it will be fixed soon.

CSFML and SFML.Net are also not up-to-date yet.

[Tank]

Sounds great, but doesn't work on my side. Minimal example:

Code: [Select]

#include <SFML/Graphics.hpp>

int main() {
sf::RenderWindow  window( sf::VideoMode( 1024, 768, 32 ), "TEST" );
sf::Event         event;
sf::Image         image;
sf::Sprite        sprite;

image.LoadFromFile( "listbox.png" );
sprite.SetImage( image );

while( window.IsOpened() ) {

while( window.GetEvent( event ) ) {
if( event.Type == sf::Event::Closed ) {
window.Close();
}
}

window.Clear();
window.Draw( sprite );
window.Display();
}
}


My window keeps black. Also all other SFML applications don't render anything at all, just the background.

Tested under Debian GNU/Linux (testing branch).

[Mindiell]

- windows are no longer active by default

You probably have to SetActive your RenderWindow  :wink:

[Laurent]

You probably have to SetActive your RenderWindow

I was only talking about external OpenGL commands. SFML windows are smart enough to activate theirselves when they render their drawables.

Sounds great, but doesn't work on my side

Works on Windows for me. I'll try on Linux, although the new system doesn't involve anything which is OS-specific.

[Tank]

Maybe it's a difference in the OpenGL implementations or graphics-card dependant (a GTX 260 on my side).

With more sprites (more than 100) I get this:

[Laurent]

The makefiles have also been updated so that SFML is installed to another directory by default. Make sure it doesn't conflict with previous versions.

Does the Clear() function work (try a different color than black) ?

[Tank]

The makefiles have also been updated so that SFML is installed to another directory by default. Make sure it doesn't conflict with previous versions.

SFML files are only present in /usr/local/lib/. But that Makefiles changes were not introduced in the last commit.

Does the Clear() function works (try a different color than black) ?

Yes, the Clear() function works perfectly (see screenshot above).

[Laurent]

It should work now.

[Tank]

Thank you, it's working now.

Please note that the quality of text rendering is slightly worse than before, it's a work in progress and it will be fixed soon.

Indeed, the quality decreased a lot.

I'll comment on performance soon when I'm ready to do some tests with a huge tilechat together with 3D models (regarding to old PreserveOpenGLStates()).

Keep it up!

[K-Bal]

I can't get pure OpenGL to work with SFML2. Minimal example:

Code: [Select]

#include <SFML/Graphics.hpp>
#include <GL/freeglut.h>

int main(int argc, char** argv)
{
    glutInit(&argc, argv);
    sf::RenderWindow myWindow(sf::VideoMode::GetDesktopMode(), "Ogl with SFML2");
    myWindow.UseVerticalSync(true);

    while(myWindow.IsOpened())
    {
        sf::Event event;
        while(myWindow.GetEvent(event))
        {
            switch(event.Type)
            {
                case sf::Event::Closed:
                {
                    myWindow.Close();
                    break;
                }
                default:
                {
                    break;
                }
            }

            myWindow.Clear();

            glMatrixMode(GL_PROJECTION);
            glLoadIdentity();
            glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);

            glBegin(GL_POLYGON);
            {
                glColor3f(1.0,1.0,1.0);
                glVertex3f(0.25, 0.25, 0.0);
                glVertex3f(0.75, 0.25, 0.0);
                glVertex3f(0.75, 0.75, 0.0);
                glVertex3f(0.25, 0.75, 0.0);
            }
            glEnd();
            myWindow.Flush();

            myWindow.Display();
        }
    }


    return 0;
}


[Laurent]

Look at the OpenGL sample from the SDK to see the changes.

Here is your corrected code:

Code: [Select]

#include <SFML/Graphics.hpp>
#include <GL/freeglut.h>

int main(int argc, char** argv)
{
    glutInit(&argc, argv); // ????
    sf::RenderWindow myWindow(sf::VideoMode::GetDesktopMode(), "Ogl with SFML2");
    myWindow.UseVerticalSync(true);

    while(myWindow.IsOpened())
    {
        sf::Event event;
        while(myWindow.GetEvent(event))
        {
            switch(event.Type)
            {
                case sf::Event::Closed:
                {
                    myWindow.Close();
                    break;
                }
                default:
                {
                    break;
                }
            }

            myWindow.Clear();

            myWindow.SetActive(); // <--- activate your window before OpenGL rendering

            glMatrixMode(GL_PROJECTION);
            glLoadIdentity();
            glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);

            glBegin(GL_POLYGON);
            {
                glColor3f(1.0,1.0,1.0);
                glVertex3f(0.25, 0.25, 0.0);
                glVertex3f(0.75, 0.25, 0.0);
                glVertex3f(0.75, 0.75, 0.0);
                glVertex3f(0.25, 0.75, 0.0);
            }
            glEnd();
            // myWindow.Flush(); <--- not needed

            myWindow.Display();
        }
    }


    return 0;

[K-Bal]

Okay, thank you

[Avency]

Now that I've had some time to test the new revision, I found some problems.
For me, performance has decreased a lot.
FPS have dropped from around ~6900 to ~900 (using the same OpenGL-code) or ~700 (the OpenGl code replaced with RenderQueue-code) when rendering a 2D tilemap + a few sprites.
For some odd reason the cpu usage stays at ~10-15% (instead of 25%), with drops to 1-2% which cause massive framedrops.
Older binaries linked aganst sfml 1.5 still work fine, as the previous revision of sfml2 did.
I've tried a few things like manually using the immediate mode renderer or getting rid of saving and restoring the GL-states.
I really don't know whats causing that slowdown...even if the batch renderer was slower, the GL code shouldn't be affected that much from the changes (I've looked through all files that changed in that revision and couldn't find any hint).
Even profiling with Valgrind gave no results.

Something else:
Why is the stack of render states (myStatesStack) of sf::RenderQueue fixed 16 elements?
It will cause the following code to segfault (I know that it is an artificial test case, but still)

Code: [Select]

#include <SFML/Graphics.hpp>
#include <iostream>

class TestDrawable : public sf::Drawable
{
public:
TestDrawable(int id) : mId(id)
{
}

void Render(sf::RenderTarget& target, sf::RenderQueue& queue) const
{
std::cout << mId << std::endl;

if (mId < 15)
{
TestDrawable nestedDrawable(mId + 1);

target.Draw(nestedDrawable);
}
}

private:
int mId;
};

int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600, 32), "SFML Window");

TestDrawable test(0);

window.Draw(test);
window.Display();
}
I hope that those initial problems can be sorted out, since I really like the new batch rendering interface.

[Laurent]

FPS have dropped from around ~6900 to ~900 (using the same OpenGL-code) or ~700

This doesn't mean anything... Here you're talking about less than 1 ms, which is the same difference as between 50 and 52 FPS.
Benchmarks done at such high framerates are not relevant at all, as the rendering part only represents a small percentage of the whole frame. The contribution of the event handling, window management, memory transfers, etc. is not negligible.

Why is the stack of render states (myStatesStack) of sf::RenderQueue fixed 16 elements?

This part of the code is very critical, and even a slight modification has a huge impact on performances. And in this case, using a fixed-size array is faster than using a dynamic one.

It will cause the following code to segfault (I know that it is an artificial test case, but still)

Absolutely
But nobody will ever have 16 levels of nested drawables; and if it happens, I can easily increase the limit (it just takes a little more memory).

I hope that those initial problems can be sorted out

Honestly, I don't think that having 900 FPS instead of 6900 can be called a "problem". It doesn't mean anything, and it might even give different results when you'll have more data to render.
How many drawables do you render in this program?

[Avency]

The FPS are not the problem (I usually cap them and use VSync if possible), but the framedrops definitely are. They occur at random times.
I wonder why it doesn't take full cpu. I know that this could be scheduler related, but it didn't happen witholder revisions.
I noticed that same happens with the example applications (the cpu stays at about 10% on a quad). Although the framedrops are not noticable as they are when scrolling a map, they also occur (this can be noticed best in the opengl sample).

This part of the code is very critical, and even a slight modification has a huge impact on performances. And in this case, using a fixed-size array is faster than using a dynamic one.

I thought so. There should be a note in the docs or even range checking if the performance penalty isn't too high.