Hi Fellows,
This is the issue, which become more and more visible with the growing complexity of designs,... as our F360's proficiency grows even faster then our egos.
I do experience the similar mouse traumas on windows in the context of more than basic projects (>1500 dimensions + animated joints)
I have posted some trembles about (in good faith ) few times.
My current sensing of the issue is as follows (although I bet, developers know better):
- mouse process runs inside F360 thread(s), which from time to time is/are overwhelmed by our drive to do more
- pragmatically judging, ... we ... are the direct source of the problem ..
- but we are not the only ones
- increased resolution of the monitor will require more frequent mouse firing and as such, "collision threshold" on the associated thread will be lower (less complex design will cause it)
and will result in some bizarre effects ( ...the size of the app window mostly does't matter here )
- of course, on the other side F360 rendering machinery will also contribute ...
- UI of F360 is the place, where such unwelcome interference of these clashes are very visible to us
- the resolution of the issue might be very simple,... or extremely complex,.. if there are architectural mishaps involved
- the best point to start, would be to establish a couple of "mouse traps" in the F360, running within the profiler/debugger
- of course to "attract" the mouse some "incentives" would be necessary
- some of you mentioned some nice car model,... could you rent it to developers for a short drive?
- if the mouse was given a chance running freely on "Unifying Mouse Driver", chasing an external to F360 thread, the problem would likely vanish and
as an additional benefit, we would be able to fully customise ( train ) our mouses to match our vigour and thumb agility
With Regards
MichaelT
MichaelT