A really odd thing happened while investigating why my PCB CAD code is so slow.

I found that it isn't but that sometimes SIM68K takes a really long time, in computer terms, to write a text string to the screen.

It goes like this. When I start the PCB CAD it is quick, window status line updates happen too fast to follow and all is well. I can load a design, zoom, pan around, edit parts and everything works as expected.

However, if I change window size often, not always, things slow significantly. Updates are now at the rate of a few a second but the same number of simulated machine cycles, about 8000, are being executed so it's not the 68k code going wrong.

I've made a test program that replicates this problem on my machine with far less code. It's here for now.

This could well be a peculiarity of my system (Intel CPU, NVIDIA graphics) as on another machine with the same OS of similar speed (Athlon CPU, Matrox graphics) it is slow from the start.

The only thing I can think of that makes some sense is that the SIM68K draw routines stop using the graphics hardware acceleration for some reason.

Really puzzled now.

Lee.

A little extra experimenting has revealed the following.

With no or only some graphics hardware acceleration drawing is about nine updates per second at 640 x 480, four updates a second at 800 x 600 and three updates a second at 1024 x 768. This is consistent regardless of window size changes.

With full graphics hardware acceleration drawing is about fourty updates per second at 640 x 480, thirty updates a second at 800 x 600 and three updates a second at 1024 x 768. Once 1024 x 768 mode has been selected, and sometimes when switching between the other resolutions, the update rate drops to the same as, or half the speed of, the unaccelerated display and never returns to the accelerated speed.

So it may be a graphics driver/hardware problem but it is very annoying as it kills usability once the slowdown happens.

Lee.

Here are the results of my first test runs. Machine is laptop, Pentium M 2GHz, 2GB RAM, nVidia 6800 Ultra, Windows XP Pro, DirectX 9.0c

640x480
0003 to 0005

800x600
0006 to 0008

1024x768
00012 to 00016

Switching from full screen to windowed mode does not change the times. I'll try it again later today on other machines and from inside the C++ and DirectX debugger.

_________________
Prof. Kelly

My machine is not quite as new. Celeron(M) 1.8GHz, 256MB RAM, Nvidia GeForce4, XpPro SP2 and DirectX 9.0c.

640 x 480
0000 to 0001, occasionally 0003 or 0004

800 x 600
0001 to 0002, occasionally 0004 or 0005

1024 x 768
0029 to 0031, occasionally 0032 or 0033

After selecting 1024 x 768, and sometimes before, it drops to ..

640 x 480
0011 to 0014 or sometimes 0024 to 0030

800 x 600
0018 to 0021 or sometimes 0036 to 0042

1024 x 768
0029 to 0031 or sometimes 0058 to 0060

The more I switch between modes the slower these numbers become, e.g the 640 x 480 will eventually slow to 0017 to 0019 and then ..



.. followed by ..



It all goes a bit downhill from there. 8^)=

I've not tested other graphics commands to see if they suffer as well, it only seems to noticeably slow task #14 and it doesn't seem to matter much what the string length just the number of times task #14 is called.

Lee.

I am seeing a slowdown on my Acer netbook.

_________________
Prof. Kelly

I may have the problem corrected but I'm still not sure what the problem was. I ran numerous tests and could find no memory leaks or errors in the code. On systems where it worked, it worked flawlessly. On systems where it failed there was no indication of why it failed. I then took the tried and true debugging technique of replacing code. By replacing Sim68K's back buffer TCanvas with a TBitMap the error went away. I still need to run memory leak checks and clean up the new code before releasing it.

_________________
Prof. Kelly

Version 5.7.0 might correct the issue. Since I'm not exactly sure what is causing the problem (see my above post) I'm not sure if this version will correct the problem on all computers. I do know it corrected the issue on the one computer I had that exhibited the slow down.

I also took the opportunity to add a new trap task #25, see the Latest Features forum for details.

_________________
Prof. Kelly

It's not fixed, quite. Using the speed test code it is a little slower at the fastest than the previous version of Sim68K but 1024 x 768 is much faster ..

640 x 480
0003 to 0004, occasionally 0000 or 0001

800 x 600
0004 to 0005, occasionally 0001 or 0002

1024 x 768
0007 to 0008, occasionally 0004 or 0005

Now after swapping back and forth a lot it eventually drops to ..

1024 x 768
0058 to 0065

It only seems to do this going to the full screen mode and it's obvious when this happens as the status takes so long to redraw.

The good news is that on the next change of resolution it usually recovers.

Lee.