Hi


Is it possible to stop making the numbers FLICKER, so one could
SEE what's going on.


It's my new program CPU-Speed, which can be used to see how FAST
the CPU actually works, not that it is advanced or something like that.
Posted on 2002-12-09 01:31:46 by The SharK
Hi The Shark

A lot of work.

1. Subclass the edit control
2. Do your own painting on a memory DC.
3. BitBlt memory DC to edit controls DC.

KetilO
Posted on 2002-12-09 04:20:32 by KetilO
or use an additional control, with the painting method that KetilO wrote. So you could at least save the subclassing stuff.

(The CPU seems to be much too fast for the display :)
Posted on 2002-12-09 04:36:25 by beaster
What? There's a processor out there that is faster than my 80 Hz refresh monitor? I don't believe it!

Next you'll be telling me there are processors out there that have broken the Kilohertz barrier! The laws of physics simply won't allow it I tell you.

See the attached code, its a solution to a problem someone had on the board (the app freezes while it counts down because it cannot process any more messages). So in my solution to the problem I spawn a thread, and let that do the work, while monitoring it using a timer control.

Mirno
Posted on 2002-12-09 05:58:39 by Mirno
Hi mirno

The same effect could be achived with simply updateing the edit control every 1000 or so, count.

KetilO
Posted on 2002-12-09 09:39:11 by KetilO
Updating the edit when "counter & 0xFFF == 0" so to speak is perfect to stop it flickering, but given a fast enough PC, then it'll start to flicker again... Using a timer you'll overcome that because their operation is based on real time.

What's more, using a thread is much more friendly, as it doesn't lock up the program while it is busy counting away. As the benchmarking algorithm is embeded in the message, it'll block that message until it is complete, thus holding up a subsequent move or size message for example.

The actual act of trying repeatedly to paint the associated area of the screen will by its nature bias the benchmark anyway. As the processor increases in speed, so must the video subsystem (card & OS code responsible), as it will be expected to draw a whole lot of things which in turn hold up the benchmarking algo. Although this is starting to go down the road of benchmarking vs benchmarketing...

Just my opinion though, if you want to stick to monolithic single threaded applications be my guest :tongue: .

Mirno
Posted on 2002-12-09 09:59:14 by Mirno
Hi Mirno !

"Using a timer you'll overcome that because their operation is based on real time."


But if I do that, the whole idea of a CPU-Speed test is GONE,
because of the REALtime pulse from the timer, so.....hmm



Hi KetilO !

Yeah, I'll try your suggestions, seems like a good idea:alright:
Posted on 2002-12-09 16:45:51 by The SharK
Shark, mirno means that you run your code in a seperate thread. The timer remain in the origional thread with the GUI updating the editbox based on a realtime clock.

The timer shouldn't affect your speed test, only read values from it at regular intervals :) .
Posted on 2002-12-10 08:23:51 by Eóin
Hi Shark,
Here is a rewrite of your program. It should help and give you ideas for your timing display problem. You might have to change the display value time within the program to reflect your slower or faster CPU. Ask if you have any questions. Ratch
Posted on 2002-12-13 00:49:22 by Ratch
Hi KetilO

I have rewritten it, so it repaints every 255 times,
it seems to be working alright !

Is it quicker/faster to make a subclass for the Edit Control,
or in another way - what's the benefit of making it ?

"1. Subclass the edit control
2. Do your own painting on a memory DC.
3. BitBlt memory DC to edit controls DC."

hmm... I have to read some more to fully understand all your advices.....


Thanks Ratch for making the program.
It seems you use include files for other
things than equates ?
I have to study the program a little closer to make
fully benefit of it, thanks again.:alright:
Posted on 2002-12-13 09:14:53 by The SharK
Here's my version using a thread & a timer.

I needed to add a KLUDGE_FACTOR constant to slow it down (as it updates a lot less its got clocks to spare). At 6200 it about matched your pace.
I also needed to disable the button while running because the message queue is still free to process (as the button click message is finished, and not busy counting down). So the user can click again while running.

I think its all good code, but I can't for the life of me work out why its so damn fast compared to the code I posted earlier in this thread :confused:

Mirno
Posted on 2002-12-13 15:14:23 by Mirno
Hi Mirno & Shark,
Why do you go through all the jumping gyrations of computing an elapsed time from GetLocalTime, when all you have to do is a simple subtract with GetTickCount? You can directly measure the interval for almost 50 days, if necessary. Ratch
Posted on 2002-12-13 19:18:30 by Ratch
Hi Mirno !

THANKS A LOT :alright: :alright: :alright:
That helped me a lot, and I learned
some new stuff:alright:

"also needed to disable the button while running because the message queue is still free to process (as the button click message is finished, and not busy counting down). So the user can click again while running."

I thought that using a THREAD, would make the user ABLE TO CLICK "Exit", while running,
because the main thread wouldn't be so busy, right ?

Hi Ratch !

I have made a new version, which is
a combination of what you said, using
GetTickCount, and what Mirno wrote
about using a Timer and a Thread.


THANKS GUYS, GREAT HELP :alright: :alright: :alright: :alright: :alright: :alright: :alright: :alright:
Posted on 2003-03-29 13:41:08 by The SharK