Near completion of Color Pattern Toolkit: IDE, engine, and font problems (part two)

[Wilhelm Sanke]

After reporting about IDE issues in my last post I am going to look at 
apparent engine problems having come up during the development of the 
toolkit (or which again came up here). There are now differences 
concerning the operation platforms and hardly any between alternative IDEs.

2. Engine aspects:

When working and experimenting with the present form of the toolkit on a 
Windows XP computer, I noticed an occasional slowdown of performance. It 
could happen that in the middle of redrawing the 19.800 color chars the 
execution would slow down, halt, and start again with a higher speed. 
Once in a while the slowdown is of such an extent that it takes two to 
three minutes to execute the script of the respective button - the 
engine is literally "choking" (normal execution time for the scripts is 
between 500 milliseconds and 4 seconds on my main computer). This 
happens relatively seldom, but it happens during longer sessions. 
Additionally - but maybe for a similar reason - there is a general 
slight and accumulating slowdown of the performance to be noticed.

Saving and/or compacting of the stack does not help, but quitting the 
IDE and starting anew.

These facts reminded me of an engine "leak" - as Scott Raney had called 
it a few yars ago,  that occurred in a "Memory Stack" of mine. After 
about the 500th time a memory tile was turned the application suddenly 
froze. Scott Raney very soon fixed the underlying engine bug; at that 
time bug fixes were achieved mostly on the basis of personal 
correspondence or via the list, as the then Metacard community was 
arguably smaller than the Rev community today. The "Memory Stack" is 
still there and working without freezing or delays 
(<http://www.sanke.org/Software/HolidayMemory.zip>).
The same bug had been responsible for freezing the IDE when using the 
drag command to create colored lines for a higher number of consecutive 
lines.

Examining the slowdown I now have stumbled accross a real (negative) 
killer feature (for Windows XP) that I had attached to a three-year old 
rudimentary version of the color toolkit. I had experimented with using 
small thumb images as color and pattern input for further processing and 
transformation; this was achieved by setting the "screenmouseloc" to the 
pixels of a thumb image and then tranferring the "mousecolor" to the 
matrix of fields. At that time I was using Windows 98 and did not notice 
any delays.

When attaching this feature to my present version of the toolkit I got 
surprises:
Scanning an area of 100X100 pixels of an imported thumb along with 
setting the backcolor of the corresponding chars in the pattern field 
took 36 seconds. Although I had set screenloc to true, the mousecursor 
was still visible, began very fast and showed a quick slowdown of its 
horizontal movements. After finishing the scan I got an error message 
"running low on memory, script aborted", most of the screen became 
white, and a number of controls appeared at odd places, some of them 
more than once. Closing the stack was hardly possible the normal way, 
you had to "grope in the dark" to find where the necessary part of the 
MenuBar had gone to. All this on a Windows XP computer with 2 GHz and 1 
GB RAM.

I then reverted to my old stack (developed on Windows 98) that had the 
scan feature attached and which had a 60 X 45 field matrix, so the 
maximum possible scan area comprised 2700 pixels.

The first scan now took (again on the XP computer) 2700 ms 
(milliseconds), the next 6700 ms, then for each of the next consecutive 
scans an average of additional 6500 ms was needed. No disturbances like 
reported above were to be seen, but when you tried to access a script or 
other parts of the IDE between the scans this was really slow. When 
about 30 seconds scan time have accumulated the IDE breaks down like 
described above.

Using a standalone shows about the same results, so it really must be an 
engine problem. My "Visual C ++" debugger among other things points to 
an "untreated exception at XXXXX, access violation".

Test of the same stack on the Windows 98 computer: Slower speed because 
of somewhat slower CPU, but constant performance, no accumulating slower 
speed and no breakdowns!

Test of the same stack(s) on my vintage Power Book (now with Mac OS 
10.3.9, 667 MHz, 1 GB RAM):

Results of the 60X45 scan: First scan 3500 ms, the consecutive scans an 
additional 250 ms each. The slowing down is there, but no freezing or 
breaking down. Script access is slowed down, and when the stack is 
closed the screen goes black for a moment. Tried up to 6000 accumulated 
milliseconds.

Results of an 150X100 scan on the Mac. First scan 21 seconds, the next 
each about 10 seconds more. No breakdown like on Window XP, but very 
slow overall performance of the stack and the same blackout when closing.

So the engine leak is there on Windows XP and to a lesser extent on 
MacOS. I ran the stack on other XP computers, too, with similar results.

You can inspect and try out the test stack from here: 
<http://www.sanke.org/Software/ScanTest2700.zip>. This stack contains a 
size of the scan area with only relatively small increments of 
performance time that even a Windows XP computer can bear for a short time.

As I write this, the remnants of the last breakdown on the XP computer 
still show: Ragged parts of the screen show as white at the right and 
left side. Although the IDE has been closed some time ago, the File menu 
of the MenuBar is visible at the left upper corner of the screen, at a 
place where it never has been.--

Two other possibly engine-related issues in short:

- When setting the thumbs of a scrollbar through a script and lockscreen 
is set, *two* thumbs appear during the time of the screenloc until it 
extends, the old and new value at the same time. Strange as this is, it 
can of course be remedied by setting the lockscreen only after changing 
scrollbar values.

- Setting screenloc to true also is expected to speed up redrawing after 
screen changes, which works for the whole color char field as well as 
for individual horizontal and vertical lines on it. However when 
creating diagonal lines in the field (by changing the color values in a 
diagonal order) lockscreen actually "slows down" redrawing the screen - 
as compared to no lockscreen set at all. This is definitely contrary to 
what the docs say.-

See you next week with "part three" of my report, this time focusing on 
fonts problems.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>