StrokesPlus Forum
                       
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Bug and Issues
 Known Issues
 [PERMANENT] S+ gets "stuck" at gesture sometimes
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

beholder

59 Posts

Posted - 06/03/2012 :  16:30:31  Show Profile  Reply with Quote
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  Show Profile  Reply with Quote
I've noticed that S+ tends to work poorly under a heavy load.
Go to Top of Page

Rob

USA
2581 Posts

Posted - 06/03/2012 :  21:19:09  Show Profile  Visit Rob's Homepage  Reply with Quote
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.
Go to Top of Page

Rob

USA
2581 Posts

Posted - 06/03/2012 :  21:22:44  Show Profile  Visit Rob's Homepage  Reply with Quote
Setting S+ to run with realtime priority would likely resolve this issue, but not be a good idea as far as system stability goes =)
Go to Top of Page

Cerberus

Netherlands
86 Posts

Posted - 06/03/2012 :  21:40:27  Show Profile  Visit Cerberus's Homepage  Reply with Quote
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
Go to Top of Page

Rob

USA
2581 Posts

Posted - 06/03/2012 :  22:13:42  Show Profile  Visit Rob's Homepage  Reply with Quote
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.
Go to Top of Page

Hax

128 Posts

Posted - 06/04/2012 :  06:37:13  Show Profile  Reply with Quote
I've just slightly increased the DELAY values and my problem seems to be gone.
Go to Top of Page

Rob

USA
2581 Posts

Posted - 06/15/2012 :  11:24:40  Show Profile  Visit Rob's Homepage  Reply with Quote
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.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
StrokesPlus Forum © 2011-2018 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000