Windows 7 - Touchscreen operation sure would be sweet

[dermbrian]

I had been running WinCab.exe in Vista in a window instead of full screen, which "sort-of" worked on my Atom-based MSI WindTop All-in-One touchscreen PC.  Often it would take an extra keypress or two on the touchscreen to recognize a button click.

My new even bigger and faster MSI WindTop All-in-One has Windows 7 and a Pentium processor.  Its touchscreen behavior when I run WinCab windowed is far worse.  The Windows 7 operating system is clearly recognizing the touch of a button, because I see the white circle radiate out from the button on each tap.  But WinCab only reacts to about 1/10th of the keypresses.  Same with hitting escape when the database is being scanned at the beginning.  I have to keep pressing escape if I hope to stop updating the database and go directly to "Update Complete!"

I've tried changing everything I could find within Windows 7 regarding the touchscreen settings in an attempt to improve things, but no luck.  Same thing with the various graphics adapter options at the end of jukebox.ini.

DWJukebox is a great program and one-of-a-kind.  I use Album Player for the most part now, but would rather be using DWJukebox, credits, and selecting from the old-style jukebox title strips.  So, I really wanted to just bring it up and let you know that I still wish there was a way you could get the touch interface working under more modern operating systems.  I think you could eke out at least a few more $$$ from people using these miraculous new PC's if that were the case.  You certainly would from me.

Brian

[dermbrian]

Here's a short video of how the buttons 'almost' work in Windows 7 on my PC.

http://www.youtube.com/watch?v=hVpSsAFTi9Q

Brian

[Chris]

It sounds like the button or keystroke isn't staying "pressed" long enough for the jukebox to detect it.  Making the jukebox poll more often may help, at the expense of eating more CPU.  Try playing with the CPUUsage parameter in jukebox.ini and see if that helps... take it all the way up to 100 and see if you can catch your button presses more reliably.

--Chris

[dermbrian]

It sounds like the button or keystroke isn't staying "pressed" long enough for the jukebox to detect it.  Making the jukebox poll more often may help, at the expense of eating more CPU.  Try playing with the CPUUsage parameter in jukebox.ini and see if that helps... take it all the way up to 100 and see if you can catch your button presses more reliably.

--Chris

First thing I tried.  OK, maybe the third or fourth.   As far as I can tell, that parameter makes no difference at all in letting WinCab see the keypress more consistently in Windows (7).  I don't think it made a difference in Vista, either. 

Brian

[Chris]

Hm.  Does changing that setting actually make DWJukebox consume more CPU in Windows 7?  How much CPU does it max out at in Task Manager?

[dermbrian]

Hm.  Does changing that setting actually make DWJukebox consume more CPU in Windows 7?  How much CPU does it max out at in Task Manager?

Yes.  The task manager shown CPU usage increases from about 5-6 percent with when set at 10 to about 39 percent when set at 100.  The touchscreen buttons are actually a little more responsive, but not much.

Increasing the application priority in Task Manager from its default NORMAL to HIGH improves touchscreen performance yet again, with buttons usually being recognized within 1-3 presses.  But that's as good as I can get it.  The application priority reverts to normal every time you close WinCab and restart it, but there is a freeware app that allows you to permanently change the priority of a process.


Brian

[Chris]

It should peg out at 100... either I'm doing something wrong or Windows 7 has a new way of dealing with apps that are less willing to give up a time slice.

[Chris]

Okay... I have an idea of what to do about this.  If it works it may solve my touchscreen problems on Vista, too.

[Chris]

Sorry to keep asking you to troubleshoot, but I have a couple of questions...

If you set DebugLevel=1 and CPUUsage=10 in jukebox.ini, run the jukebox, play a song and try to change some pages, and then exit (letting the juke run at least a minute or two), then check the jbdebug.log file... near the end of the log will be a line like:

0:01:29.46,1,GUI_EXIT,"Idle loop average: 44916 loops/sec"

If you could do that with both CPUUsage at 10 and at 100 and post what yours says for this line at both settings it would help me understand this.  Thanks!

--Chris

[Chris]

near the end of the log will be a line like:

0:01:29.46,1,GUI_EXIT,"Idle loop average: 44916 loops/sec"

Some explanation of what I am looking at here...

Ordinarily, Windows sends a message to an application that a key has been pressed or the mouse has moved, etc.  These mssages stack up in a queue so the app can process them asynchronously as needed.  DWJukebox, however, ignores this and looks at the actual state of the hardware as it passes through its idle loop.  Naturally, there is a risk of missing an event, but theoretically this idle loop should happen so often that this synchronous operation should not be a problem.  In the case of my development machine, you can see that 44,916 idle loops are processed on average every second.  Theoretically, to miss a keystroke or button press, a key would have to be pressed and released in less than 1/45,000th of a second. The human finger is just not capable of moving this fast.  At CPUUsage=100, I get 202,521 loops/sec, so my chances of missing a keystroke or mouse button press should be non-existent.

Now in reality, this rate is not constant.  When a page change is in progress or the sound buffer is being refilled, the idle loop doesn't run.  There are limiters in place, however, that are supposed to keep these types of events from interfering with reading input.  The juke runs an internal clock that ticks 100 times a second, and actions such as animation and refilling the buffer are not supposed to be able to happen more than once per "tick", to keep the juke from spinning its wheels rather than watching the keyboard.

Every x number of times through the idle loop, DWJukebox will tell Windows "Okay, go do something else for a bit", releasing its timeslice.  This is where theere is theoretically the biggest chance of losing input.  In this case, x is the CPUUsage setting times 10, so at 100 it will process 1000 times before it allows Windows to do something else.  Looking at the code, this is probably not enough.
Tinkering with how this setting is applied, I cannot get the CPU usage over 50% (300,000 loops/sec) on my system.  I used to be able to peg out the CPU.  It is probably not a coincidence that this is a dual-core system, so that may have something to do with it.

[dermbrian]

With CPU Usage set to '10'

GUI_EXIT,"Idle loop average: 75983 loops/sec


With CPU Usage set to '100'

GUI_EXIT,"Idle loop average: 183593 loops/sec




Sorry for the delay in replying.  I've been working 12 hour shifts and sleeping.

I also had to find a way to get the jbdebug.log file created.  Since I have dwjukebox in my Program Files directory, Windows 7 does not like programs making changes to files within that folder.  I had to run wincab.exe as administrator as the only way that the program would write to the same directory as the .exe file.  Or at least that seems to be the only way. 

Recall also that I run wincab.exe in a window, since that is the only way the touchpad works at all.  Full screen, the touchscreen doesn't work in Vista or newer OS's. 

Thanks for taking a look at it, Chris. 

[Chris]

Yeah, Vista and Windows 7 use a different method of accesing pointing devices... I have some sample code (that I think you ponted me to some time ago, actually) that I spent a few hours trying to integrate.. of course that code won't work on systems earlier than Windows XP.  What a pain....

While I was digging, I also found some of the code that is likely responsible for incompatibility with certain MP3's and odd charaters showing up in album or file names... not my code, but code in the library I use to extract ID3 information.  So I've got some overhauling to do, it looks like.