(long) Transparent IDE elements and other problems

[Wilhelm Sanke]

As the release date for the final version of Rev 2.2 is hopefully coming 
nearer, I think it useful to continue the discussion - which I started 
in thread "Speed tests of 2.2B1" - about problems that come up when 
Revolution has to deal with larger stacks, or more precisely with even 
small stacks that, however, contain larger numbers of objects. It is 
certainly common practice for an individual or a firm that intends to 
turn out a quality product to test this product under more severe 
conditions to find out possible limitations and thereby to reveal 
underlying flaws that would not become visible under fine-weather 
conditions.-

Monte Goulding has succeeded in resolving part of the problems for the 
Application Builder:
The build time for my 3300-fields stack, which was instrumental in 
reducing the speed problems of the AB in so far as it provided an 
incentive to look into the problems, was reduced by him from 20 minutes 
to 20 seconds. This 3300-fields stack is now in the hands of the Rev 
team, who thus will be able to reproduce the findings I will talk about 
in a moment. The standalone build time for my somewhat more extreme 
stack with 5400 fields was reduced from about 45 minutes to one minute, 
which is indeed a substantial gain.
Still, the Metacard Standalone Builder achieves much better results with 
only one second for each of these stacks, but this may be due to the 
fact that in Metacard moving the necessary resources and attaching an 
engine are treated as separate processes.
Anyway, when you know what to expect, a build time up to one minute with 
Rev could be considered a reasonable time frame.

A somewhat related thread was "What is Rev doing?" in January on the 
use-revolution list where the CPU use of Revolution was discussed. One 
culprit has been identified, namely the "revscriptedit" command that is 
sent every 500 milliseconds regardless of what is happening else in the 
Rev IDE. There must be, however, more CPU-draining processes going on.
The speed problems increase with the growing number of controls. There 
is a direct relationship; the assumption that the Rev IDE is monitoring 
all controls on a card at the same time, apparently somehow constantly 
looping over all controls could not be far off the mark.
Dan Shafer´s remark (Tue Mar 23 "(long): my wishlist for rev 3.0")

"...I'd spend three hours trying to
figure out why something didn't work. In general, I hate development
environments that are so "helpful" they do things behind my back."

seems to be appropriate in this context, too.--

For my tests I used a Windows XP computer with 2 GHz and 1 MB RAM, but 
the results were similar on two other Windows 98 computers (with 
different graphics cards). The Rev version tested is 2.2RC2.

Overview of the issues:

- "White-washing" Revolution
- button delays
- transparency of IDE elements
- special problems of Object Inspector and Application Browser

1. "White-washing" Revolution

- start Revolution
- open a test stack with 1600 or more controls on a card
- open the Windows Task Manager
- click on the test stack to set the focus (this is important)

Now move the Windows Task Manager over the test stack or IDE elements 
like tools stack and Menubar. It will now serve as an eraser tool, erase 
all controls on its path and leave a white background on stack and IDE 
elements behind, i.e. NOT on the other parts of the screen.
Depending on the number of controls the surface of stack and IDE 
elements will be restored after a few seconds, after about 10 seconds 
for the 5400-fields stack.

To repeat the test, first click on the stack again, then move the Task 
Manager.

You can also use other non-Revolution windows on your screen to achieve 
these effects.
 Maybe your open Revolution folder is behind the test stack. Click on it 
to bring it to the front, then move it over the stack or IDE elements. 
The same "white-washing" occurs. To repeat, first click on the test 
stack, then bring the folder window to the front again and drag it.

This "white-washing" does not occur with my 1200-fields test stack (also 
in the hands of the Rev team via Monte Goulding) or other stacks with 
less controls, so the dividing number is somewhere between 1200 and 1600 
controls.

Most importantly, it does not happen (with any number of controls) when 
"suppress messages" is checked in menu button "Development".
This clearly indicates that internal IDE processes are responsible for 
the white-washing.

There are still other instances of "white-washing" which I will not 
analyse here.

2. Button Delays

I mentioned such effects in thread "Speed tests of 2.2B1" and tried to 
narrow down what was going on.

- start Revolution
- open test stack 5400
- choose browse tool clicking at the tools stack
  This will cause the first "button delay" because it will take 10 
seconds until the "hand" button is down.
- click on any button of the test stack (note: this is the first click 
on a control after the stack has been opened)

What happens?
* Nothing happens for 10 seconds then
* the button appears in its pressed-down state.
* After another 10 seconds the dotted rectangle appears inside the 
button area that indicates that the button has received the focus.
* And again, after another 10 seconds the button finally comes up again 
and now the script begins executing.

Together, this is a 30-seconds delay. For the 3300 stack the whole delay 
is about 9 seconds.

When you now (after having clicked once on a button after the stack was 
opened) click on any *other* (important, see below) button, you get a 
delay of 20 seconds; the first phase described above is apparently 
skipped and the button appears immediately in its pressed-down state.

When you click on the same button again - any "same" button whitout 
clicking on a different button in between - no delays happen (the IDE 
apparently remembers which button was clicked last).

The same holds more or less for IDE buttons, the delays here are about 
10 seconds.

When "suppress messages" is checked, the buttons behave as normal, but 
the scripts are not executed because their messages are also suppressed.

Using "Suspend Development Tools" (with "suppress messages" unchecked) 
just hides the IDE elements, but does not prevent the button delays.
This can only be achieved with the SHIFT key down while choosing 
"Suspend Development Tools".

The article "About Revolution for experienced programmers" in the docs 
states

"To test your application in a "clean" environment without any of 
Revolutions`s own menus, palettes, or other parts of the development 
environment, choose Development menu Suspend Development Tools."

They should have added at this point "but you need to hold down the 
Shift key to completely "clean" the environment".

3. Transparency of IDE elements and stacks

- start Revolution
- open the 5400-fields test stack
- remain in "select" mode (pointer button pressed)
- right-click on a button
- choose "Edit Script" from the pulldown menu

The script editor immediately comes up as "transparent", i.e. only the 
decorations and borders of the script windows are visible. Tools stack 
and Message Box (if open) disappear; why is that??.
After ten seconds the background and contents of the script editor come up.
When you close the script editor, the tools stack and the message box 
reappear as transparent, and only after another 10 seconds their surface 
is restored.

The same "transparency" occurs when you choose - in the above sequence - 
"Property Inspector" instead of "Edit Script", the only difference being 
that this time tools stack and Message Box do not disappear! Why is that??

Another type of transparency can be produced with two overlapping stacks:

- open a stack with 1600 or more controls
- open a small stack with maybe three controls that overlaps
- click on the 1600+ test stack to bring it to the front
- now click on the small stack

The small stack will come to the front immediately, but as "transparent" 
like the script editor and property inspector. After ten seconds it will 
be fully visible.-

To better inspect the "object (property) inspector" of Rev I opened 
stack "revpalette" - or with its other name "revtemplatepalette" (why 
these different stack names??) - in the "clean" Metacard environment; 
"clean" is a quote here, see above under "2.".
Interestingly, if you try to open "revpalette" as a stack directly with 
"open stack" in Rev there is nothing you can see, because - when no 
object of a stack is selected - the loc of stack "revpalette" is set to 
-9999,-9999 and to make sure nobody can see it its "vis" is set to 
false. Why is that??

Anyway, in the Metacard IDE stack "revpalette" appears as visible, but 
comes up as "transparent" as described for script editor and object 
inspector. The transparency, however, is a pseudo-transparency as it is 
really a "snapshot-transparency". You can see that by moving 
"revpalette" around on the screen. Also the "overlapping-transparency"  
explained above is possible: Place "revpalette" under a Metacard stack 
and then bring it to the front again; "revpalette" will take a snapshot 
of the overlying area - and keep that snapshot.--

Opening  the script editor or the object inspector from the Message Box 
does not produce transparency or button delays.
Opening the script editor or the object inspector from the Menubar does 
not produce transparency, but a button delay of 10 seconds for the 5400 
stack.

The button-delay rules - described above - apply here, i.e.  the icon 
group of the menubar as well as  the upper group each behave as a "same" 
button when clicked in immediate sequence.

And, checking "Suppress Messages" prevents transparency and delays.


4. Special problems (and assets) of Application Browser and Object 
Inspector

a) Application Browser

Compared with the old "Application Overview" ot Rev the "Application 
Browser" has indeed has improved its speed considerably. Differences to 
Metacard remain.

Displaying the controls` properties of the 3300 stack in the 
"Application  Browser" takes 38 seconds.
The Metacard "Control Browser" needs only four seconds for the same 
stack, but displays a limited set of properties.
My own "revbrowser" - a stack now three-years old and unchanged since - 
displays the same set of properties as the "Application Browser" with 
the only exception of the "selected" column  in seven seconds.

There is certainly room to improve the speed of the "Application Browser".

A very positive feature of the Application Browser is - once it has 
displayed the properties of all controls - that accessing the script 
editor or object inspector after right-clicking on a line is immediate - 
without any transparency or button delay!

And the feature to access several control scripts at once - and also 
without delay - by right-clicking several times on different control 
lines and then choosing "edit script" - is really impressing!

By the way, my "revbrowser" - which has additional capabilities (like 
searching scripts of a whole stack with quick access to the full scripts 
of a found searchstring) - will be updated soon and have a feature to 
list, locate, and edit "unplaced backgrounds", a feature several list 
member have asked for and which is presently absent in the Rev IDE.

b) Object Inspector

While the "Application Browser" manages to display control properties 
finally even with larger number of controls - for the 5400 stack it 
needs two minutes and 30 seconds - the Object Inspector breaks down with 
such numbers.

It is impossible to access the script editor through the object 
inspector if stacks have larger number of controls.

Example: The 3300 stack is open. Choosing button "inspect menu" (the 
"right arrow") of the object inspector should bring up a menu with 
"Inspect, Property Profile, Edit Script, Send Message, and Lock 
Inspector". But only the "inspect" item of the menu appears after some 
seconds. Choosing this single menu item "inspect" lists the names and 
layers of only about 1700 controls, sometimes the last line is broken in 
the middle after "field.....".
For the 5400 stack even only 1400 control names are displayed.

The same dividing line between the 1200 and 1600 stacks - reported under 
item "white-washing" above - seems to be valid here: The full menu of 
button "Iinspect Menu"  appears with the 1200 stack while there is no 
access for the 1600 stack to the script editor because item "Edit 
Script" is not displayed in this case.--

For all four items from "white-washing" to "special problems" CPU use as 
shown in the Windows Task Manager tops 100% in the crucial phases when 
transparency, button delays or other speed problems occur.

========================================

It might again be stated - as it were as an incentive for the Revolution 
developers - that all these reported problems do not come up in the 
"clean" Metacard IDE that uses the same engine. If the Revolution IDE - 
compared with Metacard and using the "car" metaphor Geoff Canyon has 
brought up - indeed has doors and at least one seat, this should not be 
used as an excuse for deficiencies and bugs that should definitely be 
eliminated.

One problem - that seems to me to be evident through my tests with 
larger stacks - are the many interfering processes of the Revolution IDE 
that are probably meant to be "helpful" (like Dan Shafer has remarked), 
but get in the way of a solid efficiency of the IDE. Monte Goulding has 
shown that substantial improvement is possible.

As a starting point for further improvement  the "rev scripts" put into 
front- and backscripts should be carefully analyzed as to how much of 
these algorithms are really necessary and whether - if they are indeed 
not expendable - they could be streamlined.

Regards,

Wilhelm Sanke