Load image from file, scale it and save again

[The last Dodo]

Hi all,

I use ClanLib for my current project, but I had to find out, that this SDK isn't capable of doing that specific task. So I'm looking for a new library. And I want to make sure, that SFML can do it, before I have to change it again later.

Here my specific problem:

I want to support different screen-resolutions (from 800x600 to HD).
My idea: I provide all graphics in HD and scale them, everytime the user sets a new resolution. These rescaled graphics will be stored on the hard drive, so that I do not have to scale everything on every startup.

Does SFML can do that?

Thanks,
Dodo

[Laurent]

You don't have to do that. Scaling is free if it's done on the GPU (which SFML does), don't waste CPU and disk space with pre-scaled images.
With views (sf::View), solving your problem is just a matter of defining the correct view.

[Tex Killer]

Laurent, if you let the scaling to the GPU, it will be done every single frame, right?
Wouldn't that take some unnecessary GPU time, at least with smooth scaling?

[Laurent]

Trust me, you will never notice the difference. This is what GPUs are for, and they do it very well. 20 years ago your solution would be a good one, but now it's really not the way to go.

[Tex Killer]

The issue would be, then, relevant in computers with low end graphic cards, wouldn't it?

By the way, is there a way to make the GPU scale the image for us, and then get the resulting image? That aligned with the topic sugestion would solve any loose ends, right?

[The last Dodo]

Thank you for your quick anwser,

so, what you say is, that I do not need that, because der GPU ist fast enough to scale HD-graphics? Is there an (empiric) limit, where this speed ends?

I just decided to change to SFML Because after three days of waiting, I didn't get ANY response/support at the official ClanLib-Forum...

Thank you,
Dodo

[Laurent]

The issue would be, then, relevant in computers with low end graphic cards, wouldn't it?

Nop. Every GPU knows how to apply a transform, it's the most basic task of a graphics card.

By the way, is there a way to make the GPU scale the image for us, and then get the resulting image?

Well, as long as it's done once at initialization time, it doesn't really matter if it's the GPU or the CPU which does it.

so, what you say is, that I do not need that, because der GPU ist fast enough to scale HD-graphics? Is there an (empiric) limit, where this speed ends?

GPUs are not "fast enough", it's their most basic job to transform geometry, any GPU can do this. There's no limit.

[Tex Killer]

What I meant was, the task to scale every image every single frame would be heavy on low end cards (like onboard cards), and so would have to be avoided to get good performance. Is that true?

There could be moments during gameplay that the zoom changes, so everyting would have to be scaled in realtime on those situations. That is when it would be good to have the GPU doing it, even if we cache the scaled images.

I know most current video cards are far from having performance issues with 2D operations, but it is not unnusual to see a computer with onboard video card and such.

[Laurent]

What I meant was, the task to scale every image every single frame would be heavy on low end cards (like onboard cards), and so would have to be avoided to get good performance. Is that true?

No.

To be clear:

- The GPU doesn't scale the image, it transforms the points (vertices) on which the image will be mapped. Rendering the image 1:1 or scaled doesn't make any difference for the GPU, it has no idea of the size of the window, and doesn't know that one pixel of the image will exactly match one pixel of the window (or not).

- Every single vertex that is rendered is multiplied by a projection matrix. There's always one, even if you don't do anything. So whether you change it to apply a custom scale or not makes absolutely no difference. The GPU performs the exact same computations.

You should get more familiar with the rendering pipeline, it's very important to know the basics of GPUs:
http://en.wikipedia.org/wiki/Rendering_pipeline

There could be moments during gameplay that the zoom changes, so everyting would have to be scaled in realtime on those situations.

With the explanations above I hope that you understand now that there's no such thing as "scale in realtime". Things are just drawn using a slightly different projection matrix, which makes no difference for the GPU.

[Tex Killer]

Ok, thanks for the information, but how can the GPU do smooth scaling in realtime with no aditional processing than using a pre-scaled image?

As far as I know, smooth scaling requires the calculation of average colors and stuff.

Sorry if I'm being annoying... I'm just curious and want my engine to run on most of the computers.

[The last Dodo]

Hi, again

When the rendering is no problem for the GPU, I see the bottleneck at the drawing of the images (in the RAM):
When I use HD-Graphics on older computers, that do not support resolutions over 1024x768, the image has to be drawn in HD - the GPU scales it down before it is displayed, right?

Is SFML capable of drawing HD-graphics on slow computers?
(Yes, I do not want to read tutorials and documentations, before I'm absolutely sure, that I use this library)

Best regards,
Dodo

[RedIrony]

Ok, thanks for the information, but how can the GPU do smooth scaling in realtime with no aditional processing than using a pre-scaled image?

As far as I know, smooth scaling requires the calculation of average colors and stuff.

Sorry if I'm being annoying... I'm just curious and want my engine to run on most of the computers.

I think, and Laurent can correct me on this, that the reason why is because no matter what size the image is, it undergoes two transforms when it goes through the rendering pipeline, no matter what (i.e. even if the object is scaled to 1, it still undergoes the transform).

What goes on is that in CPU space, your image has translation, rotation, and scale matrices, but they aren't applied to the image. When you render the image, you pass these three matrices to the GPU. The GPU applies these matrices, transforming the image into "World Space," so that everything is relative to the origin. Later on in the process, your GPU takes your camera/viewport's parameters and transforms everything again so that it is relative to the view's position. That's the final image that you see.

So you can see, no matter what you do to the image itself, these transformations are going to be applied anyways.

[Laurent]

Ok, thanks for the information, but how can the GPU do smooth scaling in realtime with no aditional processing than using a pre-scaled image?

The GPU first transforms the vertices of the quad by the modelview and projection matrices. Then, it rasterizes the quad: for each pixel of the transformed quad, it finds the pixel of the texture that must be copied there. (I'm skipping many steps to keep things simple)
So you see, whether the image is scaled or not doesn't make any difference, the GPU will just pick different pixels in the rasterization process.

Sorry if I'm being annoying... I'm just curious and want my engine to run on most of the computers.

You're not annoying, but it's hard to explain this to someone who knows nothing about how GPUs work. You should really get more familiar with the rendering pipeline before trying to understand such things.

When I use HD-Graphics on older computers, that do not support resolutions over 1024x768, the image has to be drawn in HD - the GPU scales it down before it is displayed, right?

If the GPU is limited to, let's say, 512x512 textures, then you won't be able to create a 1024x768 texture, all you can do is to split it if you don't want to scale down.

[Tex Killer]

Laurent, I think the description you've given is only true if it is using fast scaling... If the scaling is done smoothly, every pixel from the original image is considered making the new (or at least more than the amount actually displayed). If it's not that way, it would not be smooth: aliasing would still be there.

But I really haven't studied enough of the pipeline, so my understanding of the process might be wrong.

Thank you for your time.

[Laurent]

The GPU can use various filters for when one texture pixel (texel) doesn't exactly matches one window pixel. SFML exposes the two most common: nearest-pixel and bilinear filtering. But, again, whether the image is scaled or not doesn't make any difference, bilinear filtering can be enabled or disabled independantly. And bilinear filtering is extremely cheap, it's been a core feature of GPUs for decades.