Low quality display

[elig0n]

I have Xiaomi Redmi 4 Pro and I get low quality display

[rom1v]

What is the result of:

scrcpy -v

(especially the SDL version)

What operating system do you use?

Could you provide a screenshot in 1:1 (pixel-perfect) (press Ctrl+g), please?

[elig0n]

scrcpy v1.0

dependencies:

• SDL 2.0.7
• libavcodec 57.107.100
• libavformat 57.83.100
• libavutil 55.78.100

OS: Windows 10

This is the part that fits my screen:

[rom1v]

OK, so it seems the local resize is not filtered correctly.

SDL 2.0.7

Very recent, great.

Could you try again with this change, please?

--- a/app/src/screen.c
+++ b/app/src/screen.c
@@ -19,7 +19,7 @@ SDL_bool sdl_init_and_configure(void) {
     atexit(SDL_Quit);
 
     // Bilinear resizing
-    if (!SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "1")) {
+    if (!SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "2")) {
         LOGW("Could not enable bilinear filtering");
     }

[elig0n]

is there a chance to include that in a built windows package?
I'm having trouble getting gradle via ninja

[rom1v]

I have no access to a Windows machine right now.

You don't need to build the server (so no need for gradle), just use the prebuilt server.

[jseybold]

I have the same issue and tried rebuilding from source with the bilinear filtering patch above. It still looks grainy in resize to fit mode (ctrl+x).

[XxTWMLxX]

I just had this issue.
Using the -b flag and playing with the bitrate fixed it for me.
For me on OnePlus 6 18-20 was best bitrate

scrcpy.exe -b 20

[rullskidan]

Right now I have scaling set to 200 % because it is needed on 4k display. So I tried to set scaling to 100 % and restarted application. Now it looks much better. Will this information help you fix the issue?

[rullskidan]

I actually solved it myself. scrcpy.exe > Properties > Compatibility > Change high DPI settings > Override high DPI scaling behavior > Scaling performed by: Application.

It was the buggy Windows 10 that could not do it properly. Hope ths will help someone else.

[rullskidan]

I would also like to thank you for a great software.

[Timbo3]

I am facing a similar issue with a specific phone, I tried changing bitrate and DPI settings as mentioned above but none of those things worked. I see the same problem when using other screen mirroring software like Vysor. If I press Ctrl&g, the image is great quality, but the window is way too big to use. Any advice? This software looks like a much better alternative to the free version of Vysor so would love to use it.

[rom1v]

I am facing a similar issue with a specific phone

If I press Ctrl&g, the image is great quality

So the problem is related to the resize on the computer, it should not depend on the phone. Does it?

[Timbo3]

So the problem is related to the resize on the computer, it should not depend on the phone. Does it?

If I use a different device, the quality is great at pretty much whatever size window it displays in, so it is specific to the phone.

[Timbo3]

I hope this video helps explain what I am saying bit better:

https://drive.google.com/file/d/1Ee349uUZ0QmzdTeygfrBlF_m0z1gJAd4/view?usp=sharing

[rom1v]

I hope this video helps explain what I am saying bit better

Thank you.

Your first device size is 1080x2280. The quality decrease when you resizes down the device.

Your second device size is 480x848, so in fact you don't resizes it down a lot (it's like you already pressed Ctrl+g), that's probably why the quality does not drop a lot.

Resizing the window is done on the client side, so in theory when it is broken, it should not depend on the device.

[Timbo3]

Is there anything I else I can try to fix the problem?

[rom1v]

You could try to compile without hidpi support:

meson nohidpi -Dhigh_dpi_support=false
ninja -Cnohidpi
./run nohidpi

[acadet]

I experience the same issue here, since I upgraded to >= 1.9. I did not experience any issue in 1.8 and below.

[rom1v]

If you use v1.9 and replace SDL2.dll by the one from v1.8, does it work better?

[acadet]

I am using OSX 🙃

[rom1v]

@acadet Ah yes, of course.

I'm not sure this is the same problem as this issue. Is the quality better if you press Ctrl+g (pixel-perfect)? (I guess not, contrary to #40 (comment))

Your problem is more likely a hidpi setting (each pixel takes 2×2 pixel).

[acadet]

Ctrl + g did not help, unfortunately.

[rom1v]

So it's definitely a hidpi issue.

Is there a setting similar to #40 (comment) on macOS?

[rom1v]

@MayaArche #385 (comment)

[MayaArche]

Thank you so much, sorry for my stupidity.

[rom1v]

@cjxgm I guess we should implement the libswscale approach as an option too, at least for Windows and macOS (OpenGL mipmapping is only available on Linux on scrcpy concretely).

I did a quick test, the performance seems ok (but to work properly the changes are quite intrusive, in particular, we must manually resize on window resize, create a texture on target size change instead of frame size change (but only if this option is enabled), reinit SwsContext when necessary, etc.).

[ImanCol]

use --encoder parameter and encoder available

example: --encoder OMX.google.h264.encoder

[rom1v]

I am working on supporting swscale filters.

Here is a WIP branch you could test: swscale.

scrcpy --window-height=400 --scale-filter=none
scrcpy --window-height=400 --scale-filter=trilinear  # mipmap, which is the current default if supported

# swscale filters:
scrcpy --window-height=400 --scale-filter=bilinear
scrcpy --window-height=400 --scale-filter=bicubic
scrcpy --window-height=400 --scale-filter=x
scrcpy --window-height=400 --scale-filter=point
scrcpy --window-height=400 --scale-filter=area
scrcpy --window-height=400 --scale-filter=bicublin
scrcpy --window-height=400 --scale-filter=gauss
scrcpy --window-height=400 --scale-filter=sinc
scrcpy --window-height=400 --scale-filter=lanczos
scrcpy --window-height=400 --scale-filter=spline

Thank you for your feedbacks 😉

cc @cjxgm

[rom1v]

However, for perfect responsiveness, the swscaling should be executed from a separate thread. I need to change that.

[char101]

Is there a binary build for the swscale branch? I'm on Windows so installing mingw64 is not trivial.

[rom1v]

@char101 Sorry, there isn't, and it requires to update the Windows build script to add a dependency to libswscale, so I will do that later once I get a proper implementation with scaling out of the main thread.

[char101]

Thanks. By the way, would it be possible to use adb shell wm size and adb shell wm density to make the phone resolution match the app window size? That would give the best output by eliminating any scaling.

[rom1v]

Asynchronous swscaling brings too much complexity. In bulk (probably not exhaustive):

• the window size might be changed between the request and the result
• the swscale target size depends on the window size...
• but the window size depends on the new frame size (if it changes, on rotation for example)
• the window should not be resized immediately on frame size change, but the new frame must be computed before the swscale and applied after
• all the hacky state to make fullscreen/maximized on all platforms must now be handled from two separate threads
• the swscale VS non-swscale paths are quite different (one handles the resize to be done on the CPU, the other on the GPU)

In any case, swscaling adds a lot of latency (and consumes a lot of CPU). For my 1440x3120 device, bicubic swscaling takes between 20ms and 60ms (depending on the target window size). Bilinear swscaling a bit less, but still a lot.

I'm not sure it's worth it. The complexity would necessarily add bugs for things which work correctly now, and make the whole thing difficult to maintain.

An alternative is to keep a synchronous version (like here, but it is not finished). The complexity is acceptable, but dozens of milliseconds on the UI thread is less acceptable.

The real performant solution would be to enable mipmapping (which is sufficient and solves the problem) for renderers other than OpenGL. But SDL does not provide this possibility, and writing and maintaining shaders manually for all platforms is not conceivable (not enough time/resources).

By the way, would it be possible to use adb shell wm size and adb shell wm density to make the phone resolution match the app window size?

In theory, yes, and the performance would be even better (with a smaller device size). However, in practice, on my devices, it does not work well, because it breaks the UI of apps (and even the system, the navigation bar is quite broken, the home screen and lock screen are a bit broken too…).

[pcgeek86]

I actually solved it myself. scrcpy.exe > Properties > Compatibility > Change high DPI settings > Override high DPI scaling behavior > Scaling performed by: Application.

It was the buggy Windows 10 that could not do it properly. Hope ths will help someone else.

This worked perfectly for me. My Android display is no longer pixelated when I set Windows 11 DPI compatibility to application! Thank you!

If you'd like to automate this configuration step on Windows 11, you can use the following PowerShell command. This assumes that scrcpy.exe is discoverable via your $env:PATH environment variable.

$Props = @{
  Path = 'HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\'
  Name = (Get-Command -Name scrcpy.exe)[0].Source
  Value = '~ HIGHDPIAWARE'
}
Set-ItemProperty @Props

[pcgeek86]

I am not sure what happened, but on the latest Windows 11 dev preview build (22523.1000) with the latest NVIDIA driver 511.09, the text on the screen appears pixelated again. This is happening even though I set the Scaling performed by option to Application, as I posted above.

If I press ALT + g for "pixel perfect" mode then it looks a lot better, but the window is too big for my 4k monitor.

Any ideas how I can get sharp text back with the smaller window size?

scrcpy 1.21 <https://github.com/Genymobile/scrcpy>
scrcpy 1.21

dependencies:
 - SDL 2.0.16
 - libavcodec 58.91.100
 - libavformat 58.45.100
 - libavutil 56.51.100

Screenshot of Pixelization

Scaling Option Setting

Pixel Perfect Mode (looks sharp)

[rom1v]

What's the device size ("Initial texture" in the console) and the window size?

What if you start with your device in landscape orientation?

[pcgeek86]

What's the device size ("Initial texture" in the console) and the window size?

scrcpy 1.21 <https://github.com/Genymobile/scrcpy>
C:\Users\TrevorSullivan\scoop\apps\scrcpy\current\scrcpy-server: 1 file pushed, 0 skipped. 48.9 MB/s (40067 bytes in 0.001s)
[server] INFO: Device: Google Pixel 4 XL (Android 12)
INFO: Renderer: direct3d
INFO: Initial texture: 1440x3040

What if you start with your device in landscape orientation?

The quality of the text and graphics looks a lot better in landscape mode.

scrcpy --lock-video-orientation=1

[rom1v]

1440x3040

OK, so it's just that the device screen is rendered on a surface 3040 pixels height, and downscaled by a significant factor to your monitor height.

There are two causes of bad quality related to this issue:

• hidpi scaling wrongly configured (it will be correct by default on 1.22 ad11c5b)
• display at a size way smaller than the device screen (your issue)

For the second issue, mipmapping reduces the problem: #1284
But it works only on OpenGL (SDL only exposes what's necessary to enable mipmapping on OpenGL), so it works on Linux.

You could enable OpenGL renderer on Windows, but drivers are often slow/buggy:

scrcpy --render-driver=opengl

https://github.com/Genymobile/scrcpy/blob/master/FAQ.md#the-quality-is-low

[pcgeek86]

Yeah I already tried the OpenGL renderer, based on the document you linked to. It is still rather low quality text though.

Both methods are kinda low quality compared to the landscape mode or ALT+G pixel perfect mode, under the default Direct3D renderer.

OpenGL

scrcpy --serial [2605:59c0:c4e0:901:xxxxxxxxxxxxxx]:43017 --render-driver=opengl

OpenGL (no mipmaps)

scrcpy --serial [2605:59c0:c4e0:901:xxxxxxxxxxxxxx]:43017 --render-driver=opengl --no-mipmaps

[rom1v]

Could you please test this binary (replace in v1.21): #2865 (comment)

[pcgeek86]

Could you please test this binary (replace in v1.21): #2865 (comment)

I downloaded it and enabled the Application-based DPI scaling on the binary. It's still pixelated.

EDIT: Hmmmm, actually when I run that binary from my $HOME/Downloads folder, nothing happens. No output to console, and no window pops up. Does it need to be installed somehow? When I first ran it, I had copied it into my scoop folder.

[rom1v]

@pcgeek86 Use the official v1.21 release (not scoop or other), then replace scrcpy.exe by the one provided in the comment.

[pcgeek86]

It's magically fixed itself somehow. I have high quality text again without any special parameters, and without doing pixel-perfect.

Thank you!