Skip to content
Commit 0760c958 authored by Luca Carlon's avatar Luca Carlon Committed by Albert Astals Cid
Browse files

Fix scale computation when fitting framebuffer to local view.

parent b9f0a172
Pipeline #227031 passed with stage
in 1 minute
  • Luca Carlon @lcarlon

    mentioned in commit 312c4250

    ·

    mentioned in commit 312c4250

    Toggle commit list
  • Contributor

    In my opinion this commit was wrong and broke the logic of scaling, and should be reverted. The original behaviour of the Scaling button (before my changes with slider) was that, when button was off, then there was 1:1 view. With button on, there was Fit to view scaling.

    With my slider the change was that slider allow for continuous transition between these two states.

    What @lcarlon did with this merge is that he broke the 1:1 view. Now the let position is Fit to view as it was original, but the right position fits to local height/width, whatever first best, lets call it Fit to W/H. I understand that @lcarlon maybe wanted this, but this is not how scaling work before. And I believe that some users maybe wished the Fit to W/H but it does not allow true 1:1 view. I need it and in the version before this change the Fit to W/H was possible by manually positioning the slider. The true 1:1 view is required when th remote is much larger (image multiple screen display via x11vnc) being scaled to small laptop screen. If you need to see the detail, you may need to go to 1:1 and Fit to W/H will not provide sufficient zoom.

    Below is the image presenting both, pre-merge (my original contribution) and post-merge (@lcarlon change) behaviours. The magenta and green are remote and local views respectively. The remote is larger. I consider this commit as regression.

    krdc_slider_scalling

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment