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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
