Trying to gauge image drawing limits

[Qix]

Alright, so I've made the plunge into SFML from SDL already (I really had no choice).

My application will have lots of drawable objects (2D) that will generally use images (PNGs) and just a few primitives (including text). They're contained within each other as nested drawable objects.

My questions:

• How many drawable objects (of moderate sizes) can I draw every frame without it slowing down? Is there a pre-made stress tester or benchmarker that tests something similar to this? Already answered my question. Holy crap.
• If that number is lower than I'd like, and I choose to only update the components I need to update (which would be a little more complicated as far as threading goes, but it's manageable), would it be significantly faster?
• How fast and/or direct is per-pixel drawing?
• Are transforms slow? Are transforms applied *after* drawing, or does the draw() method have to take it into account (more or less is the RenderStates object used/applied internally after the call returns?)

If there is a page that answers these questions that I'm missing, by all means link me and scold me I'm just finding out about/breaking into SFML as of a few hours ago. Just got all of the source built and incorporated into my solution and I'm ready to get designing.

Thanks for your time! Loving this library thus far.

[eXpl0it3r]

As you've already found out there's a difference between SDL 1.1 and SDL 2, which are you referting to?

Numbers usually don't say much because it all highly depnds on the underlying hardware. For SDL 1.1 you need a good CPU where as for SFML  a good graphics card will boost the numbers.

Pixel manipulation on SFML isn't really that performant, since the textures live directly on the GPU and one would need to copy around.

Transformations will get applied directly (except sf::View stuff). I don't think it's really slow since OpenGL gets used.

[Qix]

Yea I should have specified. SDL2.

Since SFML is a 'wrapper' of sorts (in the loosest meaning of the word) for OpenGL (as far as I can tell), and SDL2 is kind of the same when actually using OpenGL, I would imagine the speed is mainly up to how the API handles the lower-level calls to OpenGL libs.

I'm interested to see how well this program fares with drawing every drawable each time something needs to be updated.

I'll be sure to post later on down the road with some statistics as the program is distributed. All of the testers will be required to send in logs the program produces. The library will therefore be tested on a large range of platforms and hardware configurations, and I'd be happy to share the results!

EDIT: The other thing I was going to ask: in that benchmarking thread I linked in the OP, it referred to static vs dynamic text drawing. What's the difference?

[eXpl0it3r]

Text are also handled as textures, if you have static text, the textures/glyphs have to be calculated/prepaired once, where as on dynamic text everythings has to be calculated every frame (or so).

[Qix]

Text are also handled as textures, if you have static text, the textures/glyphs have to be calculated/prepaired once, where as on dynamic text everythings has to be calculated every frame (or so).

So how come static text was being drawn slower with SFML in the benchmark? Is it because SFML is still having to transfer around these textures between hardware/software, whereas SDL it's already on the software-side of it? Or am I just talking nonsense? :3

[eXpl0it3r]

Which benchmark did you look at? (Not sure about SFML 1.6)
Because the new ones are all faster with static text. Don't look at the percentages!! That's between SFML 2 and SDL 1.1 and SFML is obviouspy faster wirh dynamic text = higher difference = higher percentage count.

[Qix]

Ahh okay. That makes sense. Well good, that makes me even happier I made the switch.

Thanks for all of the information!

[Laurent]

How many drawable objects (of moderate sizes) can I draw every frame without it slowing down? Is there a pre-made stress tester or benchmarker that tests something similar to this? Already answered my question. Holy crap.

Don't look at the SDL vs SFML benchmark, really. It doesn't give much information, especially concerning the versions to come (SFML and SDL 2.0).

If that number is lower than I'd like, and I choose to only update the components I need to update (which would be a little more complicated as far as threading goes, but it's manageable), would it be significantly faster?

If you're talking about update, I don't know, it totally depends on your program. If you're talking about drawing (i.e. not drawing what's not visible), then yes, of course it will significantly faster, since drawing is usually the bottleneck.

How fast and/or direct is per-pixel drawing?

As fast as it can if you do it right: work on your own local array of pixels, and use Texture::update when you want to refresh it. It's fast enough for most real-time applications (like playing a HD movie at 24 fps).
You can also draw points directly as graphics entities, which is fast too.

Are transforms slow? Are transforms applied *after* drawing, or does the draw() method have to take it into account (more or less is the RenderStates object used/applied internally after the call returns?)

I don't understand your question. How could the transform be applied after the object has been drawn? And what does it have to do with the performances of transforms?
But anyway, transforms are as fast as they can be.

The questions should not be "how fast is SFML at ***", there's always a way to get good performances with it. The question is "how easy will it let me do what I want".

[Qix]

How many drawable objects (of moderate sizes) can I draw every frame without it slowing down? Is there a pre-made stress tester or benchmarker that tests something similar to this? Already answered my question. Holy crap.

Don't look at the SDL vs SFML benchmark, really. It doesn't give much information, especially concerning the versions to come (SFML and SDL 2.0).

Yea I gathered that after viewing the last few pages. I guess I'll just have to stress-test it myself and see!

If that number is lower than I'd like, and I choose to only update the components I need to update (which would be a little more complicated as far as threading goes, but it's manageable), would it be significantly faster?

If you're talking about update, I don't know, it totally depends on your program. If you're talking about drawing (i.e. not drawing what's not visible), then yes, of course it will significantly faster, since drawing is usually the bottleneck.

True; my only issue is that sub-windows (windows that are really just drawable objects) with transparent backgrounds will cause re-draws of the things below them, and calculating what all needs to be re-drawn will be a pain.

How fast and/or direct is per-pixel drawing?

As fast as it can if you do it right: work on your own local array of pixels, and use Texture::update when you want to refresh it. It's fast enough for most real-time applications (like playing a HD movie at 24 fps).
You can also draw points directly as graphics entities, which is fast too.

Perfect, this is exactly how I wanted to implement it. SDL makes it so incredibly difficult to do this.

Are transforms slow? Are transforms applied *after* drawing, or does the draw() method have to take it into account (more or less is the RenderStates object used/applied internally after the call returns?)

I don't understand your question. How could the transform be applied after the object has been drawn? And what does it have to do with the performances of transforms?
But anyway, transforms are as fast as they can be.

What I meant (and should have better worded) is whether or not the drawable's draw() method needed to take into account the state's transform that was passed to it, or if it was just a reference. I understand, now, that it is just a reference, and SFML takes care of the transforming when the rendertarget's draw() is called.

This is perfection.

The questions should not be "how fast is SFML at ***", there's always a way to get good performances with it. The question is "how easy will it let me do what I want".

Very true. So far, however, SFML is structured in the most perfect way imaginable.

Thanks for the info, Laurent! :]

[Laurent]

I'm glad SFML meets your requirements perfectly