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

[Request for tests] Refactor rendering and events position/scaling #1307

Closed
wants to merge 4 commits into from

Conversation

rom1v
Copy link
Collaborator

@rom1v rom1v commented Apr 21, 2020

This patchset removes calls to SDL_RenderSetLogicalSize() and position and scale the content (and the events) manually.

This has several benefits:

It's been a long time since I want to do this change, but it is quite "dangerous" as it impacts heavily the rendering and the event forwarding.

Therefore, I'm very interested in testing from users. Especially on macOS (but not only) (because I don't have any macOS to test), especially with HiDPI (but not only), especially with a secondary monitor (#15) (but not only).

Please also test clicks after window rotation (Ctrl+Left and Ctrl+Right, a new feature in the next release).

In theory, this is the last remaining change I would like to merge before a new release.

Thank you for your feedbacks.

EDIT: please test logical_size.8 instead

rom1v added 4 commits April 18, 2020 02:15
Only the screen knows what to do when the window is resized.

This paves the way to do other actions on window resizing.
Position and scale the content "manually" instead of relying on the
renderer "logical size".

This avoids possible rounding differences between the computed window
size and the content size, causing one row or column of black pixels on
the bottom or on the right.

This will also enable to draw items at their expected size on the screen
(unscaled).
The window dimensions are integers, so resizing to fit the content may
not be exact.

When computing the optimal size, it could cause to reduce the width and
height alternatively by few pixels, making the "optimal size" unstable.

For the same reason, during rendering, the content size could be
different from the optimal window size, leading to black borders
(supposed to be removed in optimal size).

To avoid this problem, always choose the same dimension if the choice to
resize the width or the height is in the error range.
@rom1v rom1v mentioned this pull request Apr 23, 2020
@esnaultdev
Copy link

With a setup similar to my initial post in #15

Launching scrcpy on the macOS (retina, hidpi) side, everything works well:

  • high quality image
  • no touch offset

However, the transition between screens breaks the display of scrcpy.

Moving from the retina screen to the normal screen results in a zoomed out UI
scrcpy_1_small

In that state, the touch input are actually correct based on the window size.
Resizing/rotating the window fixes the display.

Moving back the "fixed" window from the normal screen to the retina screen results in a zoomed in UI
scrcpy_2_small

Once again, rotating/resizing the window fixes the display.


Using Cmd + Left / Cmd + Right to rotate the window works well on both screens! 👍

@rom1v rom1v mentioned this pull request Apr 24, 2020
2 tasks
@rom1v
Copy link
Collaborator Author

rom1v commented Apr 29, 2020

There are still issues, and it's too risky for a release… I didn't merge it for now.

Thank you for your feedbacks :)

@rom1v rom1v closed this Apr 29, 2020
@rom1v rom1v mentioned this pull request May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants