Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Low quality display #40

Closed
elig0n opened this issue Mar 11, 2018 · 87 comments
Closed

Low quality display #40

elig0n opened this issue Mar 11, 2018 · 87 comments

Comments

@elig0n
Copy link

elig0n commented Mar 11, 2018

I have Xiaomi Redmi 4 Pro and I get low quality display
scrcpy_2018-03-11_14-46-31

@rom1v
Copy link
Collaborator

rom1v commented Mar 11, 2018

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
Copy link
Author

elig0n commented Mar 11, 2018

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:
scrcpy_2018-03-11_15-12-47

@rom1v
Copy link
Collaborator

rom1v commented Mar 11, 2018

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
Copy link
Author

elig0n commented Mar 11, 2018

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

@rom1v
Copy link
Collaborator

rom1v commented Mar 11, 2018

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
Copy link

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
Copy link

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
Copy link

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?
before
after

@rom1v rom1v added the hidpi label Sep 25, 2018
@rullskidan
Copy link

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
Copy link

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

@Timbo3
Copy link

Timbo3 commented Jan 18, 2019

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.

screenshot

@rom1v
Copy link
Collaborator

rom1v commented Jan 18, 2019

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
Copy link

Timbo3 commented Jan 18, 2019

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
Copy link

Timbo3 commented Jan 18, 2019

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

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

@rom1v
Copy link
Collaborator

rom1v commented Jan 18, 2019

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
Copy link

Timbo3 commented Jan 18, 2019

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

@rom1v
Copy link
Collaborator

rom1v commented Jan 18, 2019

You could try to compile without hidpi support:

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

@rom1v rom1v added the quality label Apr 17, 2019
@rom1v rom1v mentioned this issue Apr 17, 2019
@acadet
Copy link

acadet commented Aug 8, 2019

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

Screen Shot 2019-08-08 at 1 45 47 PM

@rom1v
Copy link
Collaborator

rom1v commented Aug 8, 2019

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

@acadet
Copy link

acadet commented Aug 8, 2019

I am using OSX 🙃

@rom1v
Copy link
Collaborator

rom1v commented Aug 8, 2019

@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
Copy link

acadet commented Aug 9, 2019

Ctrl + g did not help, unfortunately.

@rom1v
Copy link
Collaborator

rom1v commented Aug 9, 2019

So it's definitely a hidpi issue.

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

@rom1v
Copy link
Collaborator

rom1v commented Dec 11, 2020

@MayaArche #385 (comment)

@MayaArche
Copy link

Thank you so much, sorry for my stupidity.

@rom1v
Copy link
Collaborator

rom1v commented Dec 18, 2020

@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
Copy link

ImanCol commented Jan 10, 2021

use --encoder parameter and encoder available

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

@rom1v
Copy link
Collaborator

rom1v commented Feb 12, 2021

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
Copy link
Collaborator

rom1v commented Feb 13, 2021

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

@char101
Copy link

char101 commented Feb 13, 2021

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

@rom1v
Copy link
Collaborator

rom1v commented Feb 13, 2021

@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
Copy link

char101 commented Feb 13, 2021

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
Copy link
Collaborator

rom1v commented Mar 7, 2021

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
Copy link

pcgeek86 commented Dec 5, 2021

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

rom1v added a commit that referenced this issue Dec 20, 2021
@pcgeek86
Copy link

pcgeek86 commented Jan 20, 2022

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

image

Scaling Option Setting

image

Pixel Perfect Mode (looks sharp)

image

@rom1v
Copy link
Collaborator

rom1v commented Jan 20, 2022

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
Copy link

pcgeek86 commented Jan 20, 2022

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

image
image

@rom1v
Copy link
Collaborator

rom1v commented Jan 20, 2022

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
Copy link

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

image

OpenGL (no mipmaps)

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

image

@rom1v
Copy link
Collaborator

rom1v commented Jan 20, 2022

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

@pcgeek86
Copy link

pcgeek86 commented Jan 20, 2022

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.

image

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
Copy link
Collaborator

rom1v commented Jan 20, 2022

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

@pcgeek86
Copy link

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

image

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests