EASy68K  
It is currently Sat Mar 25, 2017 5:54 am

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Slow text output
PostPosted: Sun Aug 08, 2010 2:58 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Aug 08, 2010 4:20 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Aug 08, 2010 8:04 am 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1035
Location: Monroe County Community College, Monroe Michigan, U.S.A.
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Aug 08, 2010 2:23 pm 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
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 ..

Image

.. followed by ..

Image

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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Aug 09, 2010 9:33 am 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1035
Location: Monroe County Community College, Monroe Michigan, U.S.A.
I am seeing a slowdown on my Acer netbook.

_________________
Prof. Kelly


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Aug 10, 2010 2:55 pm 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1035
Location: Monroe County Community College, Monroe Michigan, U.S.A.
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 11, 2010 8:25 pm 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1035
Location: Monroe County Community College, Monroe Michigan, U.S.A.
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 11, 2010 9:15 pm 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group