Basic window memory issue

[Mörkö]

On my system the following code seems to add 10mb or ram per second:

int main() {
    sf::RenderWindow window(sf::VideoMode(320, 240), "");
    sf::Event event;
    while (window.isOpen()) {
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        glClear(GL_COLOR_BUFFER_BIT);
        window.display();
    }
}

In my system monitor, running that shows a steady increase of +10mb memory usage every second. These are my specs:

             .;ldkO0000Okdl;.                user@box
         .;d00xl:,'....';:ok00d;.            OS: openSUSE 13.1 Bottle
       .d00l'                ,o00d.          Kernel: x86_64 Linux 3.11.10-11-desktop
     .d0Kd. :Okxol:;'.          :O0d.        Uptime: 3h 0m
    'OKKKK0kOKKKKKKKKKKOxo:'      lKO'       Packages: 2570
   ,0KKKKKKKKKKKKKKKK0d:,,,:dx:    ;00,      Shell: bash 4.2.45
  .OKKKKKKKKKKKKKKKKk..oOkdl.'0k.   cKO.     Resolution: 1920x1080
  :KKKKKKKKKKKKKKKKK: kKx..od lKd   .OK:     DE: KDE 4.11.5
  dKKKKKKKKKKKOx0KKKd ;0KKKO, kKKc   dKd     WM: KWin
  dKKKKKKKKKKKK;.;oOKx,..'..;kKKK0.  dKd     WM Theme: Oxygen
  :KKKKKKKKKKKK0o;...;cdxxOK0Oxc,.  .0K:     GTK Theme: oxygen-gtk [GTK2]
   kKKKKKKKKKKKKKKK0xl;'......,cdo  lKk      Icon Theme: oxygen
   '0KKKKKKKKKKKKKKKKKKKKK00KKOo;  c00'      Font: Sans Serif
    .kKKKOxddxkOO00000Okxoc;'.   .dKk.       CPU: AMD FX-8120 Eight-Core @ 3.1GHz
      l0Ko.                    .c00l.        GPU: AMD Radeon HD 6900 Series
       .l0Kk:.              .;xK0l.          RAM: 2517MB / 7981MB
          ,lkK0xl:;,,,,;:ldO0kl,            
              .':ldxkkkkxdl:'.  

Using the github version of SFML.

Now, I thought the increase was weird in itself, and not only because I don't quite know how to identify what the actual problem is, but I really thought a lib as established as SFML shouldn't have those kinds of issues (not bashing, just being honest.)

But what's even more weird to me is that the problem seems to be dependent on the resolution of the window, and some other factors. Here are some samples I noted from trying different resolutions:

150x150: 14.9mb memory usage, no noticeable increase.
320x240: Steady memory increase by 10mb every second.
640x480: Same as 320x240.
1600x900: 5mb per second increase.
1920x1080: This is equivalent to `fullscreen windowed mode` for me. Curiously, this shows a 3mb per second increase, but if I grab and move the window so that KDE automatically resizes it to ~1280x680, then the memory stops increasing and stays at whatever it was before I moved it. Manually setting the resolution to that value results in a 7mb per second increase.

If I limit the fps using RenderWindow::setFramerateLimit() then the increase is slowed down in proportion to the rate.

So I guess my questions are: Is this a known problem? Is the problem in my code, rather than a bug in SFML? Problem is in my system? Are there any workarounds to prevent this? Can you explain what is causing the leak? Why do the amounts vary depending on window resolution?

I appreciate any information or advice, thank you.

[Ixrec]

Does this happen with a normal loop where you do clear()/draw()/display() and no raw OpenGL?  Using display() without clear() is definitely not right.

[Mörkö]

Does this happen with a normal loop where you do clear()/draw()/display() and no raw OpenGL?  Using display() without clear() is definitely not right.

Yeah it does. RenderWindow::clear() seems to implement glClear() under the hood anyway, so I didn't think there would be any practical difference in the code by calling opengl directly, even if I'm mistaken, there seems to be no change in the result / problem.

[eXpl0it3r]

The more important questions are: How do you track the "leak"? And what is your graphics driver?

Leaking drivers are nothing new.

Using the github version of SFML.

I really thought a lib as established as SFML shouldn't have those kinds of issues (not bashing, just being honest.)

Don't forget the Git version is always something in development. So if you use the latest commit, then you should never be surprise if something doesn't work/is bugged.

[Mörkö]

The more important questions are: How do you track the "leak"? And what is your graphics driver?

Leaking drivers are nothing new.

Right.

I am tracking the memory usage by nothing more scientific than launching the program and checking my system monitor.

I'm using the proprietary FGLRX drivers.

Don't forget the Git version is always something in development. So if you use the latest commit, then you should never be surprise if something doesn't work/is bugged.

Of course. I am just probing for info anyway.