Is there a good way to fit or fill an image full screen, so that it either always fills the renderer or always fits in the renderer.
This was kind of a pain on the web too, so they added the object-fit property (CSS object-fit Property).
Currently what seems to work well for fitting an image is this:
Just curious if there is a simpler way to achieve this?
Obviously the image should never be distorted and any aspect ratio image should fit in any aspect ratio renderer/quad.
I’ve got a few ideas off the top of my head.
But I’m not sure I understand your problem correctly.
The problem is that there seems to be no easy way to always fill an image without distortion, where the aspect ratio of the renderer and image can be any value. The same goes the other way, where I always want the image to fit exactly in the frame.
Imagine I want to show a slideshow but am unsure what size images or renderer/container I have.
It’s a very common thing in web design and was always a minor pain that involved Javascript until they added the object-fit property for this exact purpose.
Recently I had this pain, but as I remember, I solved it with some of these nodes shown above
What if you put a group of images here and we try to solve it elegantly?
I think all the logic you show in your patch above is little over-engineered.
Or try it yourself and tell what doesn’t suit you:
image_fitin.vl (9.2 KB)
Which object-fit behaviour do you want to achieve, contain?
@yar This only works for your texture and only for RenderTexture. What I need is that it always FitIn or FitOut in a RenderWindow. Then start changing the aspect ratio of the RenderWindow.
What you will notice is that if the aspect ratio of the RenderWindow is larger than that of the image, it will FitIn, but if it is smaller it will FitOut. That’s why I think you have to switch FitIn and FitOut based on the aspect ratio of the RenderWindow and the Texture.
To me it seems like QuadRenderer FitOut and FitIn should just work as advertised. Currently they only do what they should half the time.
Take a look at this example. Here it is correctly fitting in:
But if the renderWindow aspect ratio is lower than the image:
It is now actually doing FitOut and not FitIn.
You can try with the other textures and change the size of the RenderWindow to see what I mean. It almost seems that FitOut and FitIn only ever consider the vertical size.
@bjoern In the case of the code I posted earlier, I was doing the equivalent of object-fit: cover
fitTexture.zip (202.5 KB)
Correction: It’s weirder. FitOut actually seems to do the exact same thing as FitIn, but just scaled by 2.
If I set uniform scale back to 1 it now does the same as FitIn!?
How weird.
Seems to me like a classic case of only testing this in a certain scenario, not changing the aspect ratio, etc. Surely, this can’t be how it should work.
@seltzdesign There is a suspicion that the current state of this behaviour needs to be reconsidered. To be honest, there is some ambiguity and strangeness in this behaviour.
At the very least, the names of the menu items are misleading. At most, there are not enough menu items that are actually needed very often.
Maybe we should consider this behaviour as a bug?
I would say its a bug as well. FitIn and FitOut should work as their names suggest and currently they don’t.
To not break old patches, I would say that 2 new enums should be added and FitIn and FitOut remain unchanged. I would then add “Cover” and “Contain” to match the CSS object-fit property and should work the same way.
I am not sure if the QuadRenderer can “know” the aspect ratio of the RenderWindow though, since however this is solved, I am 99% certain you will need that for the correct calculation. At least that’s how it worked in Javascript and in the workaround I did in vvvv.
I made a simple testbench to understand where the problem is
@seltzdesign Can you have a look at this?
Fit_TestBench.vl (18.2 KB)
and modified version to be more simillar to TextureAspectRatio:
Fit_TestBench_emulate.vl (20.9 KB)
@yar Good find. Yes, the problem is that Position and Size are not exposed. We could simply connect the position and size of the renderwindow and then it would work as expected already.
You can see here how FitIn would actually work correctly when you connect the client bounds to the reference size:
I have renamed the thread and marked as a bug.
Sure, in that case I would actually just expose the rectangle input for the reference rectangle and not add any new enums.
Then old patches will still work the same and just not use the reference rectangle or if you want you can go back and fix it by supplying a reference rectangle.
That makes it an easy fix with no backwards issues.
it would be even better if you didn’t have to provide anything. it should “just work as expected”, the Quad has all the information to do that, it can retrieve the correct rectangle from the render pipeline, but it would need a re-make of the quad transformation operation to be in the draw call instead of update.
I’d like to bring it up again
We seem to have roughly figured out how to “fix” this using Skia. But there seems to be no way to do this with Stride. I haven’t been able to get the textured quad to display normally for hours now, and it doesn’t fit on the screen (when it depends on whether the long side is vertical or horizontal). Is there any way we can get this to work again? Because it looks like a whole bunch of nodes are broken because of this.
