Opened 6 months ago

Closed 6 months ago

#11742 closed defect (fixed)

BACKENDS: Android - The UI appears somewhat blurry in high resolutions

Reported by: antoniou79 Owned by: antoniou79
Priority: normal Component: Port: Android
Version: Keywords: blurry, GUI
Cc: Game:

Description (last modified by antoniou79)

As reported here by member Vince

I'm running that version on a Redmi Note 7 with Android 10, 6.3 inches at 2340 x 1080.
The image looks exactly the same using standard renderer and antialised renderer.

A connected issue seems to be that the display remains unaffected when:

  • switching the Renderer via Misc Tab between "Standard Renderer" and "Antialiased Renderer".
  • checking or unchecking the Filter graphics checkbox via Graphics Tab

Shouldn't some visual change be observed in the above two cases when changing the settings?

https://forums.scummvm.org/viewtopic.php?p=89569#p89569

Attachments (5)

Screenshot-2020-09-29-16-02-30-698-org-scummvm-scummvm.jpg (35.0 KB ) - added by antoniou79 6 months ago.
overlay_small_filtered.png (107.0 KB ) - added by criezy 6 months ago.
overlay_small_nearest.png (51.4 KB ) - added by criezy 6 months ago.
overlay_big_filtered.png (229.0 KB ) - added by criezy 6 months ago.
overlay_big_nearest.png (113.4 KB ) - added by criezy 6 months ago.

Download all attachments as: .zip

Change History (18)

comment:1 by antoniou79, 6 months ago

Description: modified (diff)

comment:2 by antoniou79, 6 months ago

Description: modified (diff)

comment:3 by ccawley2011, 6 months ago

It looks like filtering is always enabled on the texture for the overlay. However, this appears to be deliberate, judging by this comment:

We always filter the overlay with GL_LINEAR. This assures it's readable in case it needs to be scaled and does not affect it otherwise.

comment:4 by falken1975, 6 months ago

It should be possible for the user to choose freely. Otherwise there is no point in differentiating between Standard renderer and Antialiased renderer.

in reply to:  4 comment:5 by antoniou79, 6 months ago

Replying to ccawley2011:

It looks like filtering is always enabled on the texture for the overlay. However, this appears to be deliberate, judging by this comment:

We always filter the overlay with GL_LINEAR. This assures it's readable in case it needs to be scaled and does not affect it otherwise.

Right, I noticed that the GUI always had "filtered graphics" enabled, although I didn't trace it to the code that explained it. I'll probably look there to see if there's something to be done to improve the image quality / crispness.

Replying to falken1975:

It should be possible for the user to choose freely. Otherwise there is no point in differentiating between Standard renderer and Antialiased renderer.

It's actually the "Filter graphics" checkbox via the Graphics Tab that controls this kind of filtering.

The Standard rendered vs Antialiased, as discussed today on Discord, only affect rounding of corners on GUI elements (and not at all the fonts). So it's probably that that setting continues to work, but it doesn't result to much of a noticeable change.

comment:6 by criezy, 6 months ago

For a bit of context, the overlay (and OSD) used to respect the graphics filter flag. This was changed 7 years ago in commit https://github.com/scummvm/scummvm/commit/bb1d49ba9cbdb5b50cbce0c6d714d2fd2e3c6da9 that limited the overlay surface size to the maximum texture size supported by the GPU and thus introduced a potential scaling when rendering the overlay.

in reply to:  6 comment:7 by antoniou79, 6 months ago

Replying to criezy:

For a bit of context, the overlay (and OSD) used to respect the graphics filter flag. This was changed 7 years ago in commit https://github.com/scummvm/scummvm/commit/bb1d49ba9cbdb5b50cbce0c6d714d2fd2e3c6da9 that limited the overlay surface size to the maximum texture size supported by the GPU and thus introduced a potential scaling when rendering the overlay.

I don't have much experience with the graphics modules on ScummVM so I'm probably not the right person to try and find a possible fix.

However, my question (which might be dumb) is why don't we use the GL_NEAREST for when "Filtered Graphics" is disabled. Wouldn't that produce a crispier image?
There's actually some code that does exactly this here:
https://github.com/scummvm/scummvm/blob/be9372d817bcf230ff9ecc350477d7a423855e4a/backends/graphics/opengl/texture.cpp#L48

but it's not used? I am not sure.

comment:8 by criezy, 6 months ago

why don't we use the GL_NEAREST for when "Filtered Graphics" is disabled

As I wrote, it used to do that before commit bb1d49b.
I don't know why this was changed other than the comment that was added in that change ("This assures it's readable in case it needs to be scaled."). My guess is whoever implemented and tested that found that with small texture sizes using GL_NEAREST made the text hard to read.

I just made a few screenshots with a hack to limit the overlay size and I will had them to this ticket so that you can see for yourself what it gives.

But it seems to me that we could indeed respect the "Filter Graphics" option. Nearest scaling may not be pretty in some cases, but it seems readable enough to navigate in the Options and enabled filtering if the user does not like it.

by criezy, 6 months ago

Attachment: overlay_small_filtered.png added

by criezy, 6 months ago

Attachment: overlay_small_nearest.png added

by criezy, 6 months ago

Attachment: overlay_big_filtered.png added

by criezy, 6 months ago

Attachment: overlay_big_nearest.png added

comment:9 by criezy, 6 months ago

The code change to respect the Filtered graphic option is as follow:

diff --git a/backends/graphics/opengl/opengl-graphics.cpp b/backends/graphics/opengl/opengl-graphics.cpp
index 8af87abcc2..5a939995e5 100644
--- a/backends/graphics/opengl/opengl-graphics.cpp
+++ b/backends/graphics/opengl/opengl-graphics.cpp
@@ -124,6 +124,10 @@ void OpenGLGraphicsManager::setFeatureState(OSystem::Feature f, bool enable) {
                        _cursor->enableLinearFiltering(enable);
                }
 
+               if (_overlay) {
+                       _overlay->enableLinearFiltering(enable);
+               }
+
                break;
 
        case OSystem::kFeatureCursorPalette:
@@ -961,7 +965,7 @@ void OpenGLGraphicsManager::handleResizeImpl(const int width, const int height,
                // We always filter the overlay with GL_LINEAR. This assures it's
                // readable in case it needs to be scaled and does not affect it
                // otherwise.
-               _overlay->enableLinearFiltering(true);
+               _overlay->enableLinearFiltering(_currentState.filtering);
        }
        _overlay->allocate(overlayWidth, overlayHeight);
        _overlay->fill(0);

For the screenshots I added a hack on lines 954 to set the overlay width and hight to size smaller than the window (by applying a scaling factor < 1).

comment:10 by antoniou79, 6 months ago

I'm in favour of this change. It may look crude, but it is crispier and left to user choice.

That is, until a better way to scale the UI with OpenGL is implemented (how does SDL do it?).

As I understand this, this will affect all ports that support "OpenGL" "Graphic Mode", not just Android and it will be the default until user checks "filter graphics".

comment:11 by antoniou79, 6 months ago

criezy's suggested patch committed as:
https://github.com/scummvm/scummvm/commit/50d2ae3b4c8609e33187c1ec91a9dfec80cd819a

Credits go to criezy of course.

I'll leave the ticket open for a while to integrate any feedback from the change and/or possible other suggestions for solutions/optimizations.

comment:12 by antoniou79, 6 months ago

Owner: set to antoniou79
Resolution: pending
Status: newpending

comment:13 by antoniou79, 6 months ago

Resolution: pendingfixed
Status: pendingclosed

Forum member Vince confirmed that the blurriness is gone (when filtered is off).
https://forums.scummvm.org/viewtopic.php?p=89649#p89649

Closing the ticket.

Note: See TracTickets for help on using tickets.