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
