Re: [Ql-Users] Falling Cursor
James Hunkins wrote: Below is a log of the capture movie. I can forward the movie to you directly if it would help - 24k compressed. It shows the activity very well. Just let me know. 24k? That would be pretty small ;) I guess you mean 24M, but that should be okay for my mailbox, too. As to your comment about how QDT is design overall - I totally agree with the concept. You DO know that QDT is YOUR product? ;-) - when running 'normal' code, run at full speed possible Well, could you define the term normal code for me? Was wondering in this latter case if possibly the polled interrupt might not be cleared properly when the mouse is moving causing the system to re-trigger immediately thinking that the last interrupt is still there? No, the 100% CPU usage has nothing to do with the polled-interrupt whatsoever. When the mouse is moved, the CPU throttle is disabled, nothing more, nothing less. This was a decision made a long time ago and certainly right for the time, with todays CPUs one could think about a permanent throttle for example, but well, that would be work ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Falling Cursor
Hi Marcel, Below is a log of the capture movie. I can forward the movie to you directly if it would help - 24k compressed. It shows the activity very well. Just let me know. 24k? That would be pretty small ;) I guess you mean 24M, but that should be okay for my mailbox, too. 24K compressed, original is 200K - not much happening and captured as an animation so with minimal colors, very compact. 5.13 FPS, only 1 min 12 sec of time. Will send it direct to you. As to your comment about how QDT is design overall - I totally agree with the concept. You DO know that QDT is YOUR product? ;-) Sure glad I don't get confused. And that I think my product is good in concept (by the way, just starting to get back into it - working on the File Object again but taking a while to remember where I left off before the accident). And I also agree with the concept for QPC :) - when running 'normal' code, run at full speed possible Well, could you define the term normal code for me? Running a user program = normal code versus an OS which is often just sitting and waiting for something to happen with minimal activity. One trap on the normal code side, any calls to sleep the code temporarily or some other form of polling needs to really pause it activity as one would expect. Was wondering in this latter case if possibly the polled interrupt might not be cleared properly when the mouse is moving causing the system to re-trigger immediately thinking that the last interrupt is still there? No, the 100% CPU usage has nothing to do with the polled-interrupt whatsoever. When the mouse is moved, the CPU throttle is disabled, nothing more, nothing less. This was a decision made a long time ago and certainly right for the time, with todays CPUs one could think about a permanent throttle for example, but well, that would be work ;-) When you first developed QDT (I remember the DOS version) it definitely made sense. But as you said, for today's CPU power, I really don't need to be polling for mouse/keyboard/interrupts 4 million times a second :) Wish I could work that fast. Perhaps there could be an option to run all out (for slower systems) versus putting the cursor/keyboard/etc onto a polling/interrupt type control for faster systems? Jim ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Falling Cursor
Morning Marcel, Well, I only noticed 3, none of those running QPC under Windows. And I currently do not have any further ideas in this area because the things told do not add up: I agree - I'm impressed that you are still thinking about it to be honest. SNIP None of the above makes any sense does it! (Sorry, the list of points you made!). The only thought I have had this morning is that the kernel cannot be used for any 'real time' processes as it is not, without a huge patch, real time able. Windows, for example, can be used in a recoding studio as is, but Linux cannot. It can when you apply the real time patch, but not relaiable until then. I'm wondering if Linux is shceduling QPC 'badly' for some reason, but I really don't know enough about Kernel programming (yet - but I have a book!) to say for certain! What I should probably have said is that QPC does re-synchronize the SMSQ/E clock with the system clock once per minute. So even if the clock is runaway fast it will be right again one minute later. Ah, ok. No problems. I watched it for a while and it kept the same time as the xclock which was running side by side with it. SNIP Therefore my first guess would be that you're using an optical mouse that has problems with the surface it's on. I had that problem today at work! I have an optical mouse there and I was changing my monitor for a bigger one and the mouse was placed on a wooden (effect) desktop instead of the mouse mat. When the new monitor was fired up, the pointer was wandering all over the place. Shook the mouse and when it stopped, it carried on moving by itself. Put the mouse back on the pad - it remained where it was. Some mouse mats that we were issued with at work have a similar problem - they are too light coloured (I think) and the optics seem to lose the plot! Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Falling Cursor
George Gwilt a écrit : As yet I only drink wine - so the cursor falls in windows XP. Most probably, something is sending either cursor down or enter keystrokes spuriously to your window. When it happens, try to use the cursor up keystroke, to see whether that checks the movement. (probably, as soon as you release the key, it'll go down again). Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Falling Cursor
Hi George, I notice that many people have a problem with fast cursor flashing. My problem is that sometimes the cursor will not remain where it is placed, by the mouse or cursor keys. Instead it drops directly to the bottom of the screen at a constant, fairly fast, speed. Perhaps 1 1/2 seconds for a full screen. I've never had that problem under Windows and not yet under Linux/Wine. It's a most interesting problem though! Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Falling Cursor
George Gwilt a écrit : The only remedy to this occasional but persistent, fault is to exit from QPC2 and start it up again. Has anyone else found this peculiarity? Is that under windows or under wine? Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Falling Cursor
George Gwilt wrote: I notice that many people have a problem with fast cursor flashing. Well, I only noticed 3, none of those running QPC under Windows. And I currently do not have any further ideas in this area because the things told do not add up: - Fast key repeat and fast cursor flashing is a sure sign of increased poll frequency. - The poll test program though apparently testifies to a steady 50hz poll. - If the frequency actually is increased and the test still shows 50hz, the time base of the test must be off in the same way. This would be the SMSQ/E clock. - But apparently the SMSQ/E clock is also not faster than real time. To the last point, regarding this comment from Norman: | I left it running for 15 minutes and it kept exactly the same time. What I should probably have said is that QPC does re-synchronize the SMSQ/E clock with the system clock once per minute. So even if the clock is runaway fast it will be right again one minute later. My problem is that sometimes the cursor will not remain where it is placed, by the mouse or cursor keys. Instead it drops directly to the bottom of the screen at a constant, fairly fast, speed. Perhaps 1 1/2 seconds for a full screen. Well, QPC does not use any relative mouse movements which could explain the behaviour, instead it uses an absolute mouse positioning scheme. Basically the Windows mouse coordinates are directly translated to the SMSQ/E mouse position. Therefore my first guess would be that you're using an optical mouse that has problems with the surface it's on. The second guess is that something strange is going on on the SMSQ/E side of things. Did it ever happen on a clean machine? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Falling Cursor
Hi Marcel, I just did a movie capture showing both the QL clock display (the common pointer based one) and the cursor speed. I have captured it at normal speeds, stalling out, then running very slow, then taking off and then going back to normal. Below is a log of the capture movie. I can forward the movie to you directly if it would help - 24k compressed. It shows the activity very well. Just let me know. Your prior comments got me thinking about it. The watching it over time seems to hide it somewhat, at least with mine as it did catch up. I also seem to notice that sometimes different activity can change how often it happens (plus or minus) - during the SBASIC program you sent out, I wasn't reproducing the variations for some reason. Please see my comments at the bottom of the movie logging below for what it feels to be happening. - As to your comment about how QDT is design overall - I totally agree with the concept. - when running 'normal' code, run at full speed possible - amazing how fast it can run on my system - when idle (or just moving the mouse?), use the timer polling to determine when to check for mouse position and respond on the screen - should work well without tying up all the system resources, at least for just moving the cursor around Obviously from my capture, at least in my case there is something going wrong with the timer polling method used which varies quite a bit. Normally if it was working I would expect it to be using my system resources quite well. The idle or mouse movement though; I can not imagine why that would use up 100% of my CPU resources, especially if it is just sampling 50x a minute. I know that I don't need a 2.66 CPU to check and move the cursor, even with the layers involved between OSs. Was wondering in this latter case if possibly the polled interrupt might not be cleared properly when the mouse is moving causing the system to re-trigger immediately thinking that the last interrupt is still there? ___ Another question for the repeated keys - can't remember which version of Windows that was being reported on. I do remember that with Windows 98 there was a bug in the OS that was patched but was timing dependent. Once in a long, blue moon I would find either a double key entry or a control type key combination would get stuck (on or off). And when running on an emulator such as Virtual PC, it was fairly frequent. I don't recall if Windows 2000 cleared it up but I think it was better but not fixed. The problem was completely fixed by Microsoft for Windows XP and it has never given me problems. Jim === Movie Logging Clock vs. Cursor 30 frames per second capture - set capture rate (real time playback) clock showing hour:min:sec (not covered) checking cursor speed in SBASIC window versus clock speed 57:53 starts normal, clock and mouse 58:12 nothing happening so open FileManager to try to affect - moved mouse 58:12 clock stalls for several seconds during FileManager window drawing, movement 58:12 stalls during FM being displayed (not always, just this time) - even when not moving FM, might have had mouse movement (?) 58:13 started up again but running super slow - clock and mouse 58:19 takes off (clock and mouse) 58:43 back to normal Looks as if something is taking extra long (stuck in loops, other unexpected activity?) during slow time but that the system remembers up to so many interrupts and catches up at some point. It isn't tied to a system event; just seems to start up and then clear out on its own (IE: random triggered and takes a while to shift back to normal - some kind of race condition?). ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
