Closed sl-service-account closed 9 months ago
sl-service-account
commented
2 years ago Dan Linden commented at 2021-12-01T18:16:32Z
Hi CeeJay,
Could you try the Performance Improvement project viewer https://releasenotes.secondlife.com/viewer/6.4.24.565672.html and see if that helps? There are some change in this viewer which may improve mouse sync.
sl-service-account
commented
2 years ago CeeJay Tigerpaw commented at 2021-12-02T06:52:55Z
The link posted by Dan Linden immediately above takes me to a site where the only versions of the Performance Improvement viewer are for Windows. Unfortunately, I am running a Macintosh – I do not have a Windows box – so I am unable to use the Performance Improvement viewer for testing. (Unless there is a MacOS version somewhere you haven't told me about yet.)
sl-service-account
commented
2 years ago Dan Linden commented at 2021-12-02T18:33:36Z
Right, sorry. Here is a direct link to a Mac build. Note: this is a development build and has not been through QA yet, so maybe don't rely on this as your daily viewer, but we would love to get feedback on if this fixes dragging the map. If you're not comfortable with downloading this, that's fine. We should have a mac build on the website by next week. https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/91719/831375/Second_Life_Project_Viewer_Performance_Improvement_6_5_1_566443_x86_64.dmg
sl-service-account
commented
2 years ago CeeJay Tigerpaw commented at 2021-12-03T00:36:31Z
Replying to Dan Linden's comment of 02/Dec/21 10:33 AM, and also have NEW INFORMATION:
Downloaded the mac build of the performance improvement viewer: NO FIX – behavior is exactly the same as on the previously cited LL and Firestorm viewers.
HOWEVER: In the interim I have learned some more about the behavior of the bug in general – I can "turn it on and off" at will, and it is even weirder than I thought at first. Here follows the entire text of a message I sent to the Firestorm folks a few days ago: Read carefully, and note that the observed behavior is just now also observed on the performance improvement viewer:
######## SNIP ########
I think I have finally traced this bug: There is something I can do to turn the bug on or off, completely predictable, works every time, and it is hard to believe.
This will only make complete sense if you are a Macintosh user, though I expect the general idea of what is going on will be familiar to users of other systems.
The Macintosh "System Preferences" application has a panel which the user can use to adjust the operating system's understanding of where the user's monitors are located at the user's physical workstation. In that panel, each monitor is represented by a blue rectangle, sized in proportion to the actual monitor's actual screen size. Thus if the user has two monitors, A and B, the user might position the blue rectangle representing monitor A just to the left of the one representing monitor B. With that setup, when the user uses the mouse to move the graphics cursor, moving the graphics cursor off the right side of monitor A will cause it to pop into view immediately on the left side of monitor B, and so on. The user can drag the blue panels around at will, to match where the monitors actually are.
I expect that Windows and Linux have similar systems but I have not used them enough to know.
Now here is what I do to control the bug: I have three monitors, two little ones (HP2509s) and a big one (ViewSonics XG270QC). When the blue rectangles that represent them are positioned on the System Preferences panel so that their top edges are all lined up – you could lay a ruler on the screen and it would be exactly flush with the three top edges – the bug disappears. But when I move the blue panel that represents the big monitor the slightest bit up or down, the bug reappears. Then I realign the monitors and it disappears again, et cetera ad nauseam. This works like clockwork, every time, all the time, and it continues to work like clockwork even after rebooting my Macintosh and power-cycling all the monitors.
I was previously blindsided into thinking that it took many restarts to fix the bug, because sometimes when I restart, the monitor positions come up wrong in the System Preferences panel, and I fix them as a matter of course. I did not realize that was changing the bug behavior.
So this actually appears to be an Apple problem – some part of that System Preferences panel software is messing up what it tells the OS about cursor position, and the exact circumstances in which that happens are TBD – the cursor works as expected most of the time.
I will do some more research and report this one to Apple, but based on past experience I am betting that they will try to pass the buck and blame either the ViewSonics monitor or the LL / Firestorm viewers.
End of line ...
######## UNSNIP ########
NEW DATA CONTINUES:
I have also noticed that at least one other application DOES NOT have the mouse-drag problem: Apple's "Maps" application (on the Macintosh) uses mouse-drag to move the map, and it works fine. Thus it appears that this bug simultaneously involves
o SL software, and ...
o Apple software, and ...
o The ViewSonics XG270QC monitor – whether the ViewSonics's side of the issue is hardware or software is TBD.
Realistically, that probably means there will never be a solution, it will be an exercise in three companies pointing their fingers at each other in an attempt to assign blame. (Been there, done that, got lots of T-shirts.)
I have had no response from ViewSonics on the bug I filed with them yet, and I have not yet filed a bug report with Apple – I want to get all my ducks in a row before I do that.
I will be glad to assist with further tests if you should wish it.
sl-service-account
commented
2 years ago Dan Linden commented at 2021-12-06T18:59:11Z
Good find, Ceejay! This is a duplicate of BUG-230867. I will mention this bug and the additional odd behavior you mention in our internal issue.
What just happened?
I am seeing some very odd viewer behavior when I use option-mouse-down or option-press-trackpad to drag the observed location in the World Map. I am using a 2019 Apple Mac Pro, running Big Sur 11.6.1. What happens is that when I place my graphics cursor in the map portion of the World Map window, and then do option-mouse-down or option-press-trackpad, the graphics cursor goes to a fixed location, a bit below the World Map display, and stays there, no matter how I move the mouse or stroke the trackpad. This of course makes "dragging" the World Map position impossible – the map moves in the same direction and keeps going as long as I hold "option" down.
Furthermore ...
o The behavior occurs in both the current LL viewer (6.5.0.565607 (64bit)) and in Firestorm 6.4.13.
o The behavior does not occur in several other applications – which are not SL viewers – that use option-drag. Option-drag works normally everywhere else I have tested it, it seems be broken only in SL viewers.
o The behavior only occurs when the SL window is opened on one of my three monitors – a ViewSonics XG270QC. My other two monitors are old HP2509s. Both Firestorm and the LL viewer exhibit normal option-drag behavior when I open them with the windows on the HP2509s, and other applications have normal option-drag behavior on all three monitors.
o What is more, if I slide an open SL viewer back and forth between an HP2509 and the ViewSonics, the behavior of the already-opened window changes – it works properly when it is on the HP2509s but not when it is on the ViewSonics.
o I have of course logged in and out of SL many times, and restarted my Mac as well, power-cycling both the computer and all monitors. The odd thing is, that restarting everything sometimes fixes it and sometimes does not. You heard that right, the effect of a complete restart on this bug is not repeatable, and I am mystified.
Speaking as a software engineer who has occasionally modded some of the old LL viewers for personal projects, I begin to think this is a bug in some portion of the common code used by both Firestorm and the LL viewer, that is somehow triggered by the ViewSonics monitor, and the business about the effect of restarts is a complete mystery to me.
The ViewSonics is a fairly high-end gaming monitor, but I am not a gamer, I just bought it to get high-quality colors and contrast in a moderately large (27-inch) monitor; I am using it in as "normal" a way as possible. It has a 70-page manual and a substantial on-board setup system with menu access, but so far I have found nothing in it that has anything to do with how the graphics cursor moves. Possibly its most distinctive feature in this context is that it is 2560 x 1440 pixels. I wish I had some other big monitors to run tests on, but I don't.
I have contacted ViewSonics support about this matter, but it will likely be several days before they get back to me (and I expect it will take you folks several days as well).
What were you doing when it happened?
Just trying to move the world map around so I could use it to examine nearby regions.
What were you expecting to happen instead?
Expecting the world map to drag corresponding to mouse or trackpad movement.
Other information
The problem occurs both in the current LL viewer and in Firestorm: I have loaded the LL viewer's environment below, and here is the corresponding information about Firestorm, just for your reference:
Firestorm 6.4.13 (63251) Mar 1 2021 13:24:44 (64bit / SSE2) (Firestorm-Releasex64) with Havok support Release Notes
You are at 57.4, 215.9, 562.7 in Rosehaven Borderlands located at simhost-062cf1f67b91edf81.agni SLURL: http://maps.secondlife.com/secondlife/Rosehaven%20Borderlands/57/216/563 (global coordinates 231993.0, 264920.0, 562.7) Second Life Server 2021-10-25.565008 Release Notes
CPU: Intel(R) Xeon(R) W-3235 CPU @ 3.30GHz (3300 MHz) Memory: 196608 MB OS Version: Mac OS X 10.16.0 Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:42 PDT 2021; root:xnu-7195.141.8~1/RELEASE_X86_64 x86_64 Graphics Card Vendor: ATI Technologies Inc. Graphics Card: AMD Radeon Pro W5500X OpenGL Engine Graphics Card Memory: 8085 MB
OpenGL Version: 2.1 ATI-4.6.20 HiDPI display mode: 0
RestrainedLove API: (disabled) libcurl Version: libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.8 nghttp2/1.40.0 J2C Decoder Version: KDU v8.0.6 Audio Driver Version: FMOD Studio 2.01.08 Dullahan: 1.7.0.202008031101 CEF: 81.3.10+gb223419+chromium-81.0.4044.138 Chromium: 81.0.4044.138 LibVLC Version: 2.2.8 Voice Server Version: Not Connected Settings mode: Firestorm Viewer Skin: Firestorm (High Contrast) Window size: 2538x1391 px Font Used: Deja Vu (96 dpi) Font Size Adjustment: 0 pt UI Scaling: 1 Draw distance: 256 m Bandwidth: 1250 kbit/s LOD factor: 3 Render quality: Ultra (7/7) Advanced Lighting Model: Yes Texture memory: 750 MB (1) VFS (cache) creation time (UTC): 2021-10-15T6:8:42 Built with Clang version 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.12) Packets Lost: 64/33333 (0.2%) November 24 2021 20:10:49 SLT
Links
Related
Duplicates
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-231471 | | Summary | Dragging the World Map fails on a particular monitor -- running on MacOS Big Sur | | Type | Bug | | Priority | Unset | | Status | Closed | | Resolution | Duplicate | | Reporter | CeeJay Tigerpaw (ceejay.tigerpaw) | | Created at | 2021-11-25T04:20:59Z | | Updated at | 2021-12-06T19:03:42Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2021-12-01T12:16:32.326-0600', "Is there anything you'd like to add?": "The problem occurs both in the current LL viewer and in Firestorm: I have loaded the LL viewer's environment below, and here is the corresponding information about Firestorm, just for your reference:\r\n\r\nFirestorm 6.4.13 (63251) Mar 1 2021 13:24:44 (64bit / SSE2) (Firestorm-Releasex64) with Havok support\r\nRelease Notes\r\n\r\nYou are at 57.4, 215.9, 562.7 in Rosehaven Borderlands located at simhost-062cf1f67b91edf81.agni\r\nSLURL: http://maps.secondlife.com/secondlife/Rosehaven%20Borderlands/57/216/563\r\n(global coordinates 231993.0, 264920.0, 562.7)\r\nSecond Life Server 2021-10-25.565008\r\nRelease Notes\r\n\r\nCPU: Intel(R) Xeon(R) W-3235 CPU @ 3.30GHz (3300 MHz)\r\nMemory: 196608 MB\r\nOS Version: Mac OS X 10.16.0 Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:42 PDT 2021; root:xnu-7195.141.8~1/RELEASE_X86_64 x86_64\r\nGraphics Card Vendor: ATI Technologies Inc.\r\nGraphics Card: AMD Radeon Pro W5500X OpenGL Engine\r\nGraphics Card Memory: 8085 MB\r\n\r\nOpenGL Version: 2.1 ATI-4.6.20\r\nHiDPI display mode: 0\r\n\r\nRestrainedLove API: (disabled)\r\nlibcurl Version: libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.8 nghttp2/1.40.0\r\nJ2C Decoder Version: KDU v8.0.6\r\nAudio Driver Version: FMOD Studio 2.01.08\r\nDullahan: 1.7.0.202008031101\r\n CEF: 81.3.10+gb223419+chromium-81.0.4044.138\r\n Chromium: 81.0.4044.138\r\nLibVLC Version: 2.2.8\r\nVoice Server Version: Not Connected\r\nSettings mode: Firestorm\r\nViewer Skin: Firestorm (High Contrast)\r\nWindow size: 2538x1391 px\r\nFont Used: Deja Vu (96 dpi)\r\nFont Size Adjustment: 0 pt\r\nUI Scaling: 1\r\nDraw distance: 256 m\r\nBandwidth: 1250 kbit/s\r\nLOD factor: 3\r\nRender quality: Ultra (7/7)\r\nAdvanced Lighting Model: Yes\r\nTexture memory: 750 MB (1)\r\nVFS (cache) creation time (UTC): 2021-10-15T6:8:42 \r\nBuilt with Clang version 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.12)\r\nPackets Lost: 64/33333 (0.2%)\r\nNovember 24 2021 20:10:49 SLT", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'I am seeing some very odd viewer behavior when I use option-mouse-down or option-press-trackpad to drag the observed location in the World Map. I am using a 2019 Apple Mac Pro, running Big Sur 11.6.1. What happens is that when I place my graphics cursor in the map portion of the World Map window, and then do option-mouse-down or option-press-trackpad, the graphics cursor goes to a fixed location, a bit below the World Map display, and stays there, no matter how I move the mouse or stroke the trackpad. This of course makes "dragging" the World Map position impossible -- the map moves in the same direction and keeps going as long as I hold "option" down.\r\n\r\nFurthermore ...\r\n\r\no The behavior occurs in *both* the current LL viewer (6.5.0.565607 (64bit)) *and* in Firestorm 6.4.13.\r\n\r\no The behavior does *not* occur in several other applications -- which are not SL viewers -- that use option-drag. Option-drag works normally everywhere else I have tested it, it seems be broken only in SL viewers.\r\n\r\no The behavior *only* occurs when the SL window is opened on one of my three monitors -- a ViewSonics XG270QC. My other two monitors are old HP2509s. Both Firestorm and the LL viewer exhibit normal option-drag behavior when I open them with the windows on the HP2509s, and other applications have normal option-drag behavior on all three monitors.\r\n\r\no What is more, if I slide an open SL viewer back and forth between an HP2509 and the ViewSonics, the behavior of the already-opened window changes -- it works properly when it is on the HP2509s but not when it is on the ViewSonics.\r\n\r\no I have of course logged in and out of SL many times, and restarted my Mac as well, power-cycling both the computer and all monitors. The odd thing is, that restarting everything *sometimes* fixes it and sometimes does not. You heard that right, the effect of a complete restart on this bug is not repeatable, and I am mystified.\r\n\r\nSpeaking as a software engineer who has occasionally modded some of the old LL viewers for personal projects, I begin to think this is a bug in some portion of the common code used by both Firestorm and the LL viewer, that is somehow triggered by the ViewSonics monitor, and the business about the effect of restarts is a complete mystery to me.\r\n\r\nThe ViewSonics is a fairly high-end gaming monitor, but I am not a gamer, I just bought it to get high-quality colors and contrast in a moderately large (27-inch) monitor; I am using it in as "normal" a way as possible. It has a 70-page manual and a substantial on-board setup system with menu access, but so far I have found nothing in it that has anything to do with how the graphics cursor moves. Possibly its most distinctive feature in this context is that it is 2560 x 1440 pixels. I wish I had some other big monitors to run tests on, but I don\'t.\r\n\r\nI have contacted ViewSonics support about this matter, but it will likely be several days before they get back to me (and I expect it will take you folks several days as well). \r\n', 'What were you doing when it happened?': 'Just trying to move the world map around so I could use it to examine nearby regions.', 'What were you expecting to happen instead?': 'Expecting the world map to drag corresponding to mouse or trackpad movement.', 'Where': "Region doesn't seem to matter -- I have tried four or five different regions and seen the same behavior. Mostly I have tested at or near http://maps.secondlife.com/secondlife/Rosehaven%20Borderlands/57/216/563, which is my home location.\r\n\r\nI am operating on a 2019 Mac Pro (MacPro7,1) running MacOS Big Sur 11.6.1. The monitor involved is a ViewSonics XG270QC. My web browser is Safari 15.1 (though this does not appear to be a web-related bug).", } ```