Great suggestion.

Now I'm hyped for 6.0 :D
Any chance we're gonna get the temporary "hotkey to toggle filtering" solution in 4.0 if it's not too much work?

4.0 is basically feature-frozen right now so I don't think I'll be able to do that. I am trying to set up releases to move quicker in the future by having a smaller scope and automating my build process.
4.0 is nearly done but I am getting a lot of my schedule eaten up by school and CI is really time-consuming for me. I might be able to move some of that stuff back to 5.0 but I'm planning 5.0 to just be a couple of features and 6.0 to be a scaling rewrite.

Sounds great Ben, no hassle 😄

Definitely interested in this. Would be excellent for pixel art!

Either that or a toggle for certain image resolution -> screen zoom ratios.

Would accept a PR for this, shouldn't be super difficult to do besides understanding where to put it IIRC

@jurplel I came up with something:

First I simplified the scaling settings, I find it more understandable this way and don't see the need for independent checkboxes for bilinear + expensive scaling (i.e. not sure why someone would want expensive scaling enabled without bilinear also enabled as a fallback when the image goes above the window size).

Then I added the zoom percent threshold to disable smooth scaling. No manual toggle, it's strictly based on zoom level.

Would that work for you? Just the general concept, wording aside since you could easily re-label things.

Isn't using zoom percentage the wrong way to specify a threshold? Such a threshold will behave differently for different image resolutions, which I don't think is desirable behavior.

I think, as I believe @Skullfurious suggests, the threshold should be a specific ratio between image pixels and physical screen pixels. e.g. "I want smooth scaling to stop once each image pixel takes up 16 screen pixels (a 4:1 ratio in each dimension)". Or perhaps expressed in terms of rendered DPI.

This is not my field of expertise. This is my intuition speaking.

Depends on what you consider to be 100% zoom. If 100% means zoom to fit window, it would be wrong. I am considering 100% to mean 1 image pixel = 1 screen pixel (mostly, it gets more complicated with high DPI scaling, and there is a "Zoom level is relative to screen pixels" setting to control what 100% means in that context in the graphicsview-rewrite branch). So in your example if you want smooth scaling to stop at a 4:1 (single dimension) pixel ratio, you would set "Disable above" to 400%.

ok, if that's the definition of 100% zoom, then the setting makes sense. But I think some systems take into account the DPI settings of both the image and monitor, such that 100% means display an inch (as defined by the image) as an inch on screen.

There's also HDPI screen scaling to take into account. I should assume by your definition the 1:1 pixel ratio of 100% zoom is in terms of physical not virtual pixels, yes?

On Windows/Linux, assuming the graphicsview-rewrite branch gets merged, the "Zoom level is relative to screen pixels" setting is on by default, meaning 100% zoom represents physical pixels. The user can turn off that setting if they want it to work more like web browsers, where it's in virtual pixels, so a 100x100 image @ 100% would be displayed with 150x150 physical pixels with 150% display scaling.

On macOS, there kind of isn't a concept of physical pixels due to the way it handles high DPI scaling.

The issue with graphicsview-rewrite is that it doesn't behave exactly like I wanted.

My thoughts are:

• The logic is much cleaner (I wrote a lot of the zooming code when I was just learning to program)
• The animation to have it snap to center is nice, but i want it to be much quicker and more subtle
• I want the behavior to be exactly the same as it is currently otherwise, just with more options available for original size and such.

I haven't had the time to dig through it, unfortunately (and I don't see any point in the near future where I will have the time).