Small feedback on the new trilinear filtering support

[fefo-dev]

Didn't saw the release and didn'i want do post on a closed issue, so sorry in advance @rom1v

The feature works as expected with --render-driver=opengl, taking quite a toll on an 530 iGPU and with slight perceptible but easily ignobable lag on my laptop's 960M.

As expected there's a fair ammount of blurring on small details such as fonts but images/videos are more tolerant, even improved by less artifacts. Since gaming seems to be very popular use-case for scrcpy it might be very useful, as long as the computer can push the frames, but for general usage I found better to stick to the original.

While toying with OBS I found bicubic downsampling sharper without noticeable image degradation, when comparing side-by-side with its bilinear implementation.

Just some ramblings I had in mind when trying it, feel free to adress as you like. Here's some simple prints I made while testing in 1080p. Left is ogl-trilinear and right is default, both on 1.13. Hope compression doesn't kill it.

Excellent work as always, much appreciated.

[rom1v]

Thank you for your feedbacks. 👍

While toying with OBS I found bicubic downsampling sharper without noticeable image degradation, when comparing side-by-side with its bilinear implementation.

Yes, mipmapping is a quick-and-dirty solution to get a better downscale quality, but it is definitely not the best: #40 (comment)

But implementing another solution in GPU would require to write fragment shaders manually instead of relying on SDL renderers. If the target was only OpenGL (on Linux), I would probably do that (and I would had a better control on what to draw).

But since other renderers (direct3d, metal, vulkan, etc.) must still be supported, it's complicated (I would like to avoid several totally different rendering code paths). And even with only OpenGL, writing shaders compatible with all OpenGL versions on all the platforms is quite a lot of work (we do that on VLC).

As expected there's a fair ammount of blurring on small details

Without mipmapping, the quality is very low when the device definition is far higher than the scrcpy window. Therefore, maybe increasing the (negative) bias is a better compromise?

diff --git a/app/src/screen.c b/app/src/screen.c
index 0af8de8..f91afb5 100644
--- a/app/src/screen.c
+++ b/app/src/screen.c
@@ -193,7 +193,7 @@ create_texture(struct screen *screen) {
         // Enable trilinear filtering for downscaling
         gl->TexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
                           GL_LINEAR_MIPMAP_LINEAR);
-        gl->TexParameterf(GL_TEXTURE_2D, GL_TEXTURE_LOD_BIAS, -.5f);
+        gl->TexParameterf(GL_TEXTURE_2D, GL_TEXTURE_LOD_BIAS, -1.f);
 
         SDL_GL_UnbindTexture(texture);
     }

[fefo-dev]

I missed the detailed comparison on the first issue, thanks for relinking it. The -1 LOD bias looks quite close to bicubic and overall improved against the original bilinear (older default?) to my eyes, but from the thread it seems up to the viewer. Maybe let it rock and then change it - I feel like the feature will be missed by many.

From my rounds within the emulation crowd multiplat support feels like a demon, there's iffy support from all sides. Diving on it alone while people ask you for clients and stuff isn't something I would choose :P

[rom1v]

I will probably do some tests again, and I might set lod bias to -1 by default instead of 0.5 (I would like to avoid adding a command line option for that, which would be too obscure for users).

@cjxgm What do you think about -1 by default?

[cjxgm]

-1 has a little bit of sharpening artifact, but ordinary users may prefer such look. Just like TVs. They always default to an over-sharpened look and that's probably because people like it better.
So, I think it's OK to set it to -1 by default for the ordinary users, as long as there is an option to tune it for those picky eyes.

[rom1v]

I set LOD bias to -1 in ac4c8b4. 🚀