Author |
Topic |
|
beholder
60 Posts |
Posted - 06/03/2012 : 16:30:31
|
I am not sure why and when this happens but it already happened a few times for it to be an accident.
The behavior: 0. RMB is pressed 1. I do or don't do a gesture 2. RMB is released 3. gesture keeps being drawn after release of RMB 4. clicking RMB, LMB, ESC or alt-tabbing disables behavior #3 (not sure which) 5. normal gesture drawing resumes 6. normal execution of gestures DOES NOT resume 7. clicking RMB on S+ tray icon [shows menu and] resumes gesture drawing
Again I am not sure which conditions need to be there for this to happen. Seems like when my computer is disk trashing and of low performance, then this happens more frequently.
Will keep kicking into this until it rears more of the ugly self.
Prefs: Reset cancel delay ON Keep gesture drawing on top OFF Don't hide window ON Enable wheel relay ON Fire on mouse wheel scroll ON Capture modifiers OFF
Any questions/suggestions? Has anyone else experienced this stuckiness?
Current fav pr0nstar: Tiffany Thompson http://fuskator.com/full/m1sngU7WhFQ/4921_kindgirls_teen_tiffany_Tiffany+Thompson.html |
|
Hax
128 Posts |
Posted - 06/03/2012 : 16:50:31
|
I've noticed that S+ tends to work poorly under a heavy load. |
|
|
Rob
USA
2615 Posts |
Posted - 06/03/2012 : 21:19:09
|
This is always a possibility because Windows only waits so long for a hook to respond or it is skipped. This can leave S+ in a bad state where S+ thinks the RMB is still down because Windows was churning when you pressed RMB and let go of it, but S+ was fighting for system resources and wasn't able to get enough CPU time to finish processing the other queued up mouse messages and Windows decided that the mouse message has spent too much time waiting for any hooks to process it, and forwards it to the standard input queue, bypassing S+.
Meanwhile, S+ got the mouse down message, but was skipped on one or more of the subsequent mouse messages, so S+ never knew the RMB was released because Windows skipped S+. This is a hard problem to overcome. I thought I had an idea to check the button state on all mouse events where S+ thinks the stroke button is down, but since S+ is capturing the stroke button down event, calling GetKeyState doesn't actually report the stroke button as being pressed since the S+ hook handled (consumed) the stroke button down event.
I'm trying to see if there's a way to detect if the button is physically down, but I'm not having any luck since my search terms keep leading to the standard GetKeyState stuff that I'm trying to avoid. |
|
|
Rob
USA
2615 Posts |
Posted - 06/03/2012 : 21:22:44
|
Setting S+ to run with realtime priority would likely resolve this issue, but not be a good idea as far as system stability goes =) |
|
|
Cerberus
Netherlands
86 Posts |
Posted - 06/03/2012 : 21:40:27
|
quote: Originally posted by Rob
Setting S+ to run with realtime priority would likely resolve this issue, but not be a good idea as far as system stability goes =)
Interesting. I don't think I have ever seen this bug, and I use S+ all the time, of course. I'm on XP. What would happen if I set S+ to real-time priority? |
Edited by - Cerberus on 06/03/2012 21:40:52 |
|
|
Rob
USA
2615 Posts |
Posted - 06/03/2012 : 22:13:42
|
This hasn't happened to me either, it would only likely occur on lower-powered systems that are being taxed (HD thrashing, not enough RAM type of situation)
Setting to Realtime: Probably nothing, unless S+ encountered a problem, then it could possibly lock the entire system..worse than if it crashes now, where you can at least eventually recover. Though, Windows changes the priority to Normal once a S+ dialog is opened, then S+ sets it back to High on closing the dialog, so if you were to set it to Realtime, you'd have to set it back to Realtime again after opening any S+ window, so it would be a pain anyway =)
The lesson here is: don't enable Draw Gesture if your system is lower-powered and you shouldn't run into this issue. However, I'm still going to see if there's a way to mitigate this. |
|
|
Hax
128 Posts |
Posted - 06/04/2012 : 06:37:13
|
I've just slightly increased the DELAY values and my problem seems to be gone. |
|
|
Rob
USA
2615 Posts |
Posted - 06/15/2012 : 11:24:40
|
Also, it may help to uncheck the Aggressively Manage Memory option for systems experiencing this.
It sounds counter-intuitive, but by unchecking that option, you're telling S+ to NOT free up resources which it will likely reuse (and thus have to load back into memory) the next time a gesture is drawn or a S+ window is shown. Of course, this means the memory usage reported by Task Manager will jump considerably, but S+ won't have to reload things when running, which on a lower-end/taxed system could reduce S+ performance in these situations.
Something to try, anyway. |
|
|
|
Topic |
|
|
|