Does setScale() round to highest, lowest or closest pixel?

[xqbt]

I am working with a sprite and I need to set its width in pixels to desiredWidth:

float factor = desiredWidth / sprite.getLocalBounds().width;
sprite.setScale(factor, factor);

Internally, sprite's width should cancel out with itself, leaving desiredWidth behind. But this is a float value and sprite.getLocalBounds().width is integer, so how will desiredWidth be rounded?

To me, it would make sense to round it to the closest pixel in this particular case. But what happens when width * (desiredWidth / width) yields, say, 10.4?

PS I looked through the sources, but got confused.

[Hapax]

Positions/sizes etc. aren't in pixels; they are in co-ordinates, which are abstract measurements (see sf::View tutorial) that don't match pixels. It's only when they are rendered that each which pixel is used to display it is decided.

You point about desiredWidth being a float and localBounds' width being an integer means that the localBounds' width is "promoted" to float before the division so it's just one float divided by another.

[xqbt]

It's only when they are rendered that each which pixel is used to display it is decided.

That's what I wanted to ask, how will it be decided when it is rendered?

[Laurent]

It's not the job of SFML, how texels map to pixels is described by the rasterization rules of OpenGL. But honestly, I don't think you need to know these rules. What's your problem exactly?

[xqbt]

Hello!
Well, here is my concern. After executing this:

int desired width = 10;
float factor = desiredWidth / sprite.getLocalBounds().width;
sprite.setScale(factor, factor);

I just want to be sure that

sprite.getLocalBounds().width

will now be exactly equal to desiredWidth.

[Laurent]

Of course it is. Why do you think it could be different? Did you have any problem?

[xqbt]

Of course it is. Why do you think it could be different? Did you have any problem?

OK, cool! Well, I did not have any problems, but here is the thought which troubled me. Suppose we take a factor that is, say, not very nice - say PI. Then, I suppose, somewhere internally, sprite width is multiplied by PI, yielding another float. Now, this float needs to be integer (since it shows amount of pixels). Would not it make sense to ceil this float value?
If we multiply not by PI, but by desiredWidth/spriteWidth instead, we will get a float which is very close to, but not exactly (since it is a float), desired width. It might be a liitle low or a little high. Well, if we use ceil and it is a little high, we get one pixel more than needed.
But apparently rounding is used, but that was the source of my confusion.

[Hapax]

I suppose, somewhere internally, sprite width is multiplied by PI, yielding another float.

Right.

Now, this float needs to be integer (since it shows amount of pixels).

Not actually true. The float "width" is given directly to OpenGL and it decides how many pixels it wants to use depending on its current state (e.g. its view).

But apparently rounding is used, but that was the source of my confusion.

It's actually not. At least not until it's rasterized by OpenGL. At that point, it decides on how the pixels look, which also takes into consideration anti-aliasing so that a width of 10.5 would be 10 pixels and a semi-transparent pixel.
If anti-aliasing is turned off, it will be rounding somewhat inside OpenGL, yes.

[xqbt]

Hapax, thank you for the explanation!

The float "width" is given directly to OpenGL and it decides how many pixels it wants to use depending on its current state (e.g. its view)

But does OpenGL decide what will be in sprite.getLocalBounds().width?

[Laurent]

But does OpenGL decide what will be in sprite.getLocalBounds().width?

No, sprite.getLocalBounds().width simply returns sprite.getTextureRect().width (don't hesitate to look at the source code). And the texture rect is set by you, so you have everything under control.

[xqbt]

Oh, dear, getGlobal/LocalBounds() actually return FloatRect! I was thinking IntRects  Now all is clear.
Thank you, Laurent and Hapax!