Bug 7047 - Bad rubberband effect when dragging windows on macOS
Summary: Bad rubberband effect when dragging windows on macOS
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.9.0
Assignee: Pierre Ossman
URL:
Keywords: relnotes, samuel_tester
Depends on:
Blocks: 5273 5415
  Show dependency treegraph
 
Reported: 2017-09-13 16:35 CEST by Samuel Mannehed
Modified: 2017-10-17 14:28 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Samuel Mannehed cendio 2017-09-13 16:35:19 CEST
When dragging windows in the macOS client we get an ugly "rubberband effect", meaning that the window lags behind the cursor. It's easier to see if you are using the high-dpi scaling mode.

It seems to have gotten worse after bug 6079 was implemented.
Comment 3 Samuel Mannehed cendio 2017-09-13 16:44:06 CEST
Note that running vncviewer in non-high DPI mode seems to help a bit:

Right-click the ThinLinc client and choose "Show package contents". Navigate to "Contents/lib/tlclient" and right-click vncviewer. Choose "Show info" and check "Open in low resolution".
Comment 5 Pierre Ossman cendio 2017-09-14 10:01:10 CEST
I think this is just a general graphics performance issue. hidpi means having to shuffle four times as many pixels, and perform extra calculations on those pixels as well.

It seems the window manager is more efficient at scaling than the APIs we're using though. Or it is just easier to scale the entire window rather than parts of it.
Comment 6 Pierre Ossman cendio 2017-09-19 13:01:10 CEST
We've deciced to revert bug 6079.
Comment 8 Pierre Ossman cendio 2017-09-21 16:58:09 CEST
I tried to find a way to change the default but still allow users to enable high resolution if they wanted. Unfortunately I could not find a combination of settings to achieve this, so things are now back to being unconditionally low resolution.

Other than that the observed issues seem to be gone.
Comment 10 Samuel Mannehed cendio 2017-10-10 12:35:52 CEST
This is a pain to test since macOS for some reason is caching the Info.plist files.. A system reboot doesn't even reload the updated Info.plist values. Only safe way I found to accomplish this is to rename the application (mv ThinLinc\ Client.app tlclient5584.app).

I am also not seeing the desired performance improvements from disabling High DPI in the ThinLinc client. Will investigate further.
Comment 11 Samuel Mannehed cendio 2017-10-11 16:38:49 CEST
(In reply to comment #10).
> I am also not seeing the desired performance improvements from disabling High
> DPI in the ThinLinc client. Will investigate further.

So this is wierd. We are now seeing the opposite of the expected behavior. The the situation is that the "rubberband-effect" did actually get worse after the revert. So we have to decide what to do next. To sum it up:

High DPI enabled:
+ pretty text in tlclient window and options
+ smaller rubberband effect

High DPI disabled:
+ No small graphical glitches
Comment 12 Samuel Mannehed cendio 2017-10-12 10:02:30 CEST
(In reply to comment #11)
> High DPI disabled:
> + No small graphical glitches

One more advantage of High DPI disabled:
+ Uses less CPU on client machine

When furiously dragging a window around inside a session the client process uses around 20% of the CPU available on our macOS 10.12 machine in the lab.

When doing the same using the 4.8.0 client (High DPI enabled) the client process uses around 80% of the CPU available on the same client machine.
Comment 13 Pierre Ossman cendio 2017-10-17 13:16:04 CEST
We've decided to stay in "lo-dpi" mode for now.
Comment 14 Samuel Mannehed cendio 2017-10-17 14:28:07 CEST
I can verify that both tlclient and our vncviewer have forced Lo-DPI mode now.

Note You need to log in before you can comment on or make changes to this bug.