virtualbox.org

Technologov wrote:One idea is to allow integer-only scaling for software rendering. And require OpenGL for non integer scaling.

Yes. And at least, always (as is, in the future) permit power-users to select both, for example, 200.0% scaling on both axes, and nearest-neighbor scaling. No matter how these things get to be implemented (such as the potential for automatic scaling, according to the guest resolution of the moment in comparison with the host resolution).

The importance lies in permitting the user to choose integer factors in the scaling process, so that nearest-neighbor (an available option) can make sense (as it can be absurd in non-integer-factor scaling scenarios).

in BETA4, new scaling is much better (compared to BETA1). It is a bit blurry, but no longer painful on my eyes.

The problem is: the new algo is blurry even at integer-scale-ratio (i.e. 200%). BETA1 was better there. It was very sharp and beautyful. Black text. BETA2 gives me blurry & gray text even at 200% for some strange reason.
Can we revert to BETA1 algo for integer-scaled images please ?

1st image: BETA1 @ 200% = Perfect image !
2nd image: BETA4 @ 200% = Blurry image with gray text.
3rd image: BETA1 @ 150% = Causes massive eye pain after 10-20 minutes of work.
4th image: BETA4 @ 150% = Less eye pain.

Verdict: for integer scaling BETA1 algo is WAY better.

NOTE: I don't compare BETA2 & BETA3 here, as I didn't test this particular feature with them, but I presume their scaling will be similar to BETA4.

Patch.

Technologov wrote:in BETA4, new scaling is much better (compared to BETA1). It is a bit blurry, but no longer painful on my eyes.

The problem is: the new algo is blurry even at integer-scale-ratio (i.e. 200%). BETA1 was better there. It was very sharp and beautyful. Black text. BETA2 gives me blurry & gray text even at 200% for some strange reason.
Can we revert to BETA1 algo for integer-scaled images please ?

1st image: BETA1 @ 200% = Perfect image !
2nd image: BETA4 @ 200% = Blurry image with gray text.
3rd image: BETA1 @ 150% = Causes massive eye pain after 10-20 minutes of work.
4th image: BETA4 @ 150% = Less eye pain.

Verdict: for integer scaling BETA1 algo is WAY better.

I partially agree.
We should provide an option to allow the user to choose between:
"Always smooth scaling", "Integer scaling for integer scale-factor", "Always integer scaling"
And probably even more combinations. The thing which prevents it for now is that *3D accelerated* case is not that easily adjustable.
But the GUI option I mentioned above should influence both *software* and *hardware* rendering cases.
We will discuss that a bit further.

I don't see a usecase for "Always smooth scaling". It loses to "Integer scaling for integer scale-factor".
Also, at quick glance, I could not find hardware scaling code in BETA4. Do you mean using OpenGL 3D accelerator on host ?

But more discussion is good; Gives us better ideas.

Technologov wrote:Also, at quick glance, I could not find hardware scaling code in BETA4. Do you mean using OpenGL 3D accelerator on host ?

I mean the case with 3D Acceleration feature enabled, the scaling is then performed by the VBox host 3D service, not by the GUI at all.

Provide too many options via GUI is confusing. Via CLI, maybe it makes sense. (for advanced users, developers and custom frontends)
For GUI ? I'm more dubious about it.
What's the justification ?

Just I don't see any weak points for my proposal of: "Integer scaling for integer scale-factor". It looks like the best of both worlds.

Could be similar technique implemented for 3D accelerated mode ?

So can we agree :
1. on doing "interger for integer-scale" by default ? According to my tests results earlier, this gives best results.
2. if you users want options, maybe it makes sense to put them into VM properties or CLI commands (VBoxManage) ?
3. Maximum scaling ratio must be way higher than 200%. I recommend 400%. Agreed?

Dsen wrote:"Integer scaling for integer scale-factor"

Not to be an ass about proper terminology, but could as well be something on the ends of "nearest-neighbor (point) scaling at integer scale factors." ;)

At integer factors, we already have best solution. Perfect quality. See images above.

Indeed. I was just proposing an alternative body of terms!

It would probably be good to aim for the best solution now. By that I mean that integer scaling should be added in an optimal combination with other capabilities.

Here is a logic which should cover everything.

1. If scaling is disabled, render image 1:1.

2.1. Determine scaling factor. If scaling factor is manually set, respect it. Otherwise, calculate it according to settings of "auto scaling" and "integer scaling". Auto scaling tries to make the image as big as possible to fit (without distorting X:Y ratio). Integer scaling determines whether this is done in a smooth fashion or in steps. Allow downscaling as well. In case of downscaling, integer scaling can take every 2nd, 3rd, 4th, (etc.) pixel.

2.2. Render image at scaling factor.

3. Render image centered on the drawing area. When painting the image and drawing area is larger, paint remainder (surroundings) black. If image is larger than drawing area, display scrollbars. This allows running guests with resolutions larger than host, using the guest with permanent magnification, etc.

4. When user changes window size or switches to/from fullscreen, drawing area size changes and the procedure is repeated to determine new parameters and start drawing accordingly. This happens after VB Additions negotiate a new resolution with guest desktop.

Is there a scenario where this logic fails?