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

Postings relating to old VirtualBox pre-releases

Re: Scaling: needs better algo...

Postby twipley » 15. May 2015, 23:34

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).
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...

Postby Technologov » 18. May 2015, 21:02

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-percent-scaling.png
BETA1 @ 200% - Perfect image !
BETA1-200-percent-scaling.png (8.16 KiB) Viewed 4060 times
BETA4-200-percent-scaling.png
BETA4 @ 200%. Blurry image with gray text.
BETA4-200-percent-scaling.png (18.35 KiB) Viewed 4060 times
notepad-WinXP-at-150-percent-BETA1.png
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 4060 times
new-scaling.png
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 4060 times
Technologov
Volunteer
 
Posts: 3313
Joined: 10. May 2007, 16:59
Location: Israel

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

Postby Technologov » 19. May 2015, 17:24

Patch.
Attachments
vbox-scaling.patch.txt
(3.28 KiB) Downloaded 68 times
Technologov
Volunteer
 
Posts: 3313
Joined: 10. May 2007, 16:59
Location: Israel

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

Postby Dsen » 19. May 2015, 18:14

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

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

Postby Technologov » 19. May 2015, 18:18

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

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

Postby Dsen » 19. May 2015, 18:22

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

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

Postby Technologov » 19. May 2015, 20:13

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: 3313
Joined: 10. May 2007, 16:59
Location: Israel

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

Postby Technologov » 25. May 2015, 16:01

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

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

Postby twipley » 25. May 2015, 22:41

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.
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...

Postby Technologov » 25. May 2015, 22:44

At integer factors, we already have best solution. Perfect quality. See images above.
Technologov
Volunteer
 
Posts: 3313
Joined: 10. May 2007, 16:59
Location: Israel

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

Postby twipley » 25. May 2015, 22:45

Indeed. I was just proposing an alternative body of terms!
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...

Postby bostjan » 26. May 2015, 08:23

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?
bostjan
 
Posts: 5
Joined: 9. Apr 2015, 08:42

Previous

Return to Old Beta Postings

Who is online

Users browsing this forum: No registered users and 1 guest