[PATCH][Regression] BETA4: Scaling: needs better algo...

Postings relating to old VirtualBox pre-releases
twipley
Posts: 72
Joined: 5. Jul 2011, 20:46
Primary OS: Ubuntu other
VBox Version: OSE Debian
Guest OSses: Windows XP

Re: Scaling: needs better algo...

Post by twipley »

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).
Technologov
Volunteer
Posts: 3342
Joined: 10. May 2007, 16:59
Location: Israel

Re: Scaling: needs better algo...

Post by Technologov »

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.
Attachments
BETA1 @ 200% - Perfect image !
BETA1 @ 200% - Perfect image !
BETA1-200-percent-scaling.png (8.16 KiB) Viewed 6963 times
BETA4 @ 200%. Blurry image with gray text.
BETA4 @ 200%. Blurry image with gray text.
BETA4-200-percent-scaling.png (18.35 KiB) Viewed 6963 times
150% scaling with v5.0-BETA1. Causes massive eye pain after 10 minutes of work.
150% scaling with v5.0-BETA1. Causes massive eye pain after 10 minutes of work.
notepad-WinXP-at-150-percent-BETA1.png (6.37 KiB) Viewed 6963 times
150% scaling with v5.0-BETA4. Better than BETA1, as there is much less eye pain, but text is blurry and not focused. It is gray, while should be black.
150% scaling with v5.0-BETA4. Better than BETA1, as there is much less eye pain, but text is blurry and not focused. It is gray, while should be black.
new-scaling.png (16.77 KiB) Viewed 6963 times
Technologov
Volunteer
Posts: 3342
Joined: 10. May 2007, 16:59
Location: Israel

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by Technologov »

Patch.
Attachments
vbox-scaling.patch.txt
(3.28 KiB) Downloaded 86 times
Dsen
Oracle Corporation
Posts: 165
Joined: 10. Sep 2007, 10:42

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by Dsen »

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.
Technologov
Volunteer
Posts: 3342
Joined: 10. May 2007, 16:59
Location: Israel

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by Technologov »

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.
Dsen
Oracle Corporation
Posts: 165
Joined: 10. Sep 2007, 10:42

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by Dsen »

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.
Technologov
Volunteer
Posts: 3342
Joined: 10. May 2007, 16:59
Location: Israel

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by Technologov »

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 ?
Technologov
Volunteer
Posts: 3342
Joined: 10. May 2007, 16:59
Location: Israel

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by Technologov »

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?
twipley
Posts: 72
Joined: 5. Jul 2011, 20:46
Primary OS: Ubuntu other
VBox Version: OSE Debian
Guest OSses: Windows XP

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by twipley »

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." ;)
Last edited by twipley on 25. May 2015, 22:44, edited 1 time in total.
Technologov
Volunteer
Posts: 3342
Joined: 10. May 2007, 16:59
Location: Israel

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by Technologov »

At integer factors, we already have best solution. Perfect quality. See images above.
twipley
Posts: 72
Joined: 5. Jul 2011, 20:46
Primary OS: Ubuntu other
VBox Version: OSE Debian
Guest OSses: Windows XP

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by twipley »

Indeed. I was just proposing an alternative body of terms!
bostjan
Posts: 5
Joined: 9. Apr 2015, 08:42

Re: [PATCH][Regression] BETA4: Scaling: needs better algo...

Post by bostjan »

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?
Post Reply