Not clearing the contents of a RenderWindow after Display

[Kernelpanic]

Hi,
I'm a new (and happy ) SFML-User.

When I call Display(), the RenderWindow ist displayed and his contents are cleared, I can call Display() again and there is only the background.
I have searched for a function in the Documentation, but I haven't found a option to disable this cls.

This is my idea for a new feature:
void Display(bool clear = true), developers would be able to keep the content of a RenderWindow.
Would it be possible to implement that feature?

"Kernelpanic"

PS:
Sorry for my bad English - German guy  :roll:

[eleinvisible]

Hehe "ist displayed"... =D

I suppose this is decent suggestion? Except in SDL when you flip the screen it clears the contents as well (if I remember correctly)...so this may be something more technical than I understand (I'm too lazy to understand OpenGL beyond textures and vertices).

[Kernelpanic]

haha, if u have written "ist" thousand times...

I think, Flip doesnt clear the Window, but I'm not sure.
I have made one SDL-Project, and I think, I had to delete manually, it would be nice to have the choice.

Edit:
Yes, SDL_Flip doesn't clear the window.
I had the function oldRect to fill a rect with the backgroundcolor, without calling this function I get a long groove.

[Redien]

SDL uses software rendering as default if I'm not mistaken. And thus probably uses bitmaps to store the current frame in RAM. OpenGL talks directly to the graphics hardware which stores the frames in the internal video memory. Thus in SDL you would just be modifying the bitmap in RAM which was then sent to the video card (if present) by OS calls every time it needs to be updated. (I don't know anything about SDL's internals so I'm just speculating here.

This is why you only draw what you need to draw onto the bitmap as it's slower for the CPU to blit an image in RAM than using graphics hardware to draw a textured primitive.

You could do the same thing with OpenGL and store the last frame in a texture and then render it before you render the new primitives.

But this kind of defeats the original purpose as this would probably just make it slower.

[Kernelpanic]

Yes, that's the problem.
Copying it each frame makes the program much more slower.

[Redien]

Why do you need such a feature anyway?

[Nexus]

I think sometimes you could leave part of the screen - for example if you are just changing some small sprites, but must redraw the whole scene.
Isn't that a great loss of performance?

[Laurent]

The usual technique for games, even not real-time ones, is to refresh the display continuously even if no update happens. Just redraw everything every loop.

If you don't refresh your display at all, you could have problems when resizing the window, moving other windows or cursor over it, etc.

[workmad3]

It is definitely the usual process when you have hardware acceleration available The main reason being that the small gain from only drawing changed sections is offset by the extra logic and processing required to keep track of just changed sections. This changes with software rendering of course, but as SFML is designed around OpenGL and 3d hardware is so prevalent nowadays, there isn't really a need to only clear part of the screen.

[Kernelpanic]

Hey, in our discussion about SDL and Hardware we have lost the topic.
I don't search for a function like SDL_UpdateRect().
But when I Draw a sprite into a window and then call Display twice, I see only the Background.
In simple guis or turnbased games there are many parts of the window, which do not change each frame.
It would be efficient to keep the old content of the window.
You would still redraw the hole window with Display, but you wouldn't draw all the sprites again.

[workmad3]

The point I was trying to make was that with hardware acceleration, the extra logic required to track the parts that need changing is less efficient than just redrawing the entire screen (especially if your sprites are stored as textures on the graphics hardware, so don't require touching the CPU in it's renderpath).

[Kernelpanic]

Yes, right, but I have already said so:
My problem is not the Displaying of the Window, it is the Drawing of the Sprites.
I could do that:

Code: [Select]


Image img = mainwindow.Capture();
mainwindow.Display();
Sprite sprite;
sprite.SetImage(img);
sprite.SetPosition(0, 0);
mainwindow.Draw(sprite);

..but that is really slow.

[workmad3]

Why is redrawing the sprites an issue? Thats part of redrawing the window and falls under what I've already mentioned.

[Kernelpanic]

Is it really a problem, only to keep the old content?
You want to say this code is efficient?

[Redien]

There's no reason to do that kind of optimization if you don't have huge amounts of static geometry (or sprites) that never change. Even if you did have, there are ways to speed that up by using VBO's, Vertex arrays etc. or just render it to a texture and draw it to the screen before every frame.

It's generally good practice to create the game or application first and optimize later when you actually need better performance.