Hello Holger,
On 19-Apr-99 15:31:47, you wrote:
>> This is a very old discussion in the Amiga world. Actually it started when
>> Stefan Stunz decided to design MUI to handle all the user input. There is
>> not much point in carrying on this discussion here, except for the fact
>> that Java GUI based programs will all suffer of that apparent slowlyness
>> when they are just retarded.
>This is not quite true. First of all let me correct the misconception
>that the thread on which the GUI code runs (input.device vs. pplication)
>has any direct impact on the observed "speed" of the GUI. It does not.
Read back again, especially where I say "apparent slowlyness".
>The speed with which a GUI reacts to user input depends on three
>factors: Does the code responsible for the reaction/refresh get the
>CPU at all, triggered by the user input ? How quickly does it get it,
>once the decision to give it CPU time has been made ? How much CPU time
>is it allocated, once it does get the CPU ?
>The first point is only an issue for badly written applications that
>don't keep a thread in their GUI main loop at all times. Those
>applications do not appear to react to user input because they are
>otherwise busy. That is obviously sloppy programming, and a violation
>of programming guidelines, so it is pointless to discuss this and to
>use it as an argument for or against a method. Obviously it CAN be
>done correctly, and many programs do so.
It's curious you name that "sloppy programming" because this happens in
Miami Deluxe, especially when dialing to an ISP with a common modem. Try
for instance dial to a line that doesn't answer to make Miami Deluxe time
out. In the end you see Miami Deluxe hanging there for a while until with
no user interface handling: windows are not refresh nor relayed out nor
iconified.
>The second point is affected by the task switching delay, which is
>negligible in AmigaOS, unlike in Unix. It does not affect GUI reaction
>time in any measurable or noticable way.
You are neglecting the large number of IDCMP messages that are relayed to
the applications that wouldn't be needed in normal BOOPSI gadgets like for
instance MOUSEMOVE.
>The third point is once again a point where bad vs. good programming
>practice comes in. Obviously with programs using BOOPSI/gadgetclass
>a lot of work is done on input.device, which is Very Bad from a design
>point of view, see below, but appears fast to the user. Programs like
Looking faster for the user is very important. It's frustrating when
programs do not seem to reach well to user input. It raises a lot of user
dissactisfaction. This is a well studied situation in Human Factors
discipline.
>MUI simply need to make sure that their GUI event loop has a priority
>higher than zero for GUIs to "feel fast". That's easy enough to do,
>and ensures that GUIs will get "a lot of" CPU time when needed, instead
>of competing with applications.
Handling user input is always more important than non vital task. That's
why in Windows the task that has the active window gets higher priority.
>Bottom line: with everything else (GUI objects etc.) being equal, a
>single-threaded application-driven GUI engine can be just as quick and
>responsive as one driven by input.device, if the application is written
>properly.
I don't agree. Within a environment where there are tasks loading the CPU
significantly, a MUI GUI is affected a lot more than it is tolerable. Try
for instance accessing ZIP disks with a controller that uses a lot of CPU
and then see your beloved MUI GUIs crawler if they react at all.
>Actually single-threaded GUIs engine have one inherent performance
>*advantage* over multi-threaded GUI engines: they don't have the
>additional overhead of managing threads (resource locking, such as
>RastPorts, initialization/setup for rendering etc.). They can cache
>far more data than multi-threaded engines that have to worry about
>being preempted.
What you are saying basically is that in a multitasking environment it is
better to program just like you would in a non-multitasking environment:
not using the OS resources to distribute the load and the overhead by
different tasks.
>As to running gadgets on input.device being a Bad Thing: there are
>plenty of reasons for this. Just to name a few:
>- It is not scalable. Once you start piling up gadgets upon gadgets
> and interconnect them at the event level, your computer stops reacting
You don't have to interconnect BOOPSI gadgets at the event level. If you
do you should be aware of the consequences.
> to input because it is too busy reacting to input :-). You effectively
> lose the advantage of having different priorities in the first place:
> raising the priorities or GUI-triggered events, like scrolling, means
> you don't get preempted for even more important things, like mouse
> movement, making the computer feel extremely sluggish. See the "mouse
> pointer locks up when scrolling large pages" problem with programs
Exactly what I get with IBrowse.
> like Grapevine as an example. ClassAct tries to "solve" this problem
> by off-loading some work to the application (after all, getting closer
> to MUI), but this not only breaks OO information hiding principles and
> makes it impossible to cleanly subclass some types of gadgets, but
> also causes resource locking conflicts.
Subclassing can only be done properly if you antecipate its need before
designing you class tree.
>- It runs third-party (class method) code on input.device, which just
> happens to be the most critical task in the system. A bug in any
> class and the whole system dies. With application-driven systems
> like MUI only a single application dies in situations like that.
The fact is that a bug in any program may make the Amiga OS die. It isn't
be any better when a MUI program make my Amiga die. Even if my Amiga OS
does not die immediatly after a program crash I can no longer trust in the
consistency of the data in memory nor I am interested to carry on with any
dead programs in memory.
If Amiga had proper memory protection in place and you could clean dead
tasks, I would agree with you.
>- For reasons deeply rooted in computer science principles, the two
> concepts of "object oriented programming" and "multithreaded
> resource locking" are mutually exclusive. They are fundamentally
Do you know how BeOS handles GUIs? It has a separate task for application.
I was told that MUI 4 was going in this direction. That would be a great
improvement. But for now it is just a rumour.
> general OO runtime environment. BOOPSI/gadgetclass suffers exactly
> from that problem, on several levels. Most application programmers
> only know about the ObtainGIRPort() problem, which is a side effect
> of what I described above and cannot be fixed. However the problems
What aspect of the problems of ObtainGIRPort are you talking about?
> run far deeper. What do you think why whole applications are written
> in MUI, using the MUI OO environment, with lots of complex and
> interchangeable classes (editors etc.), whereas you never see
> anything like that for ClassAct or even bare BOOPSI/gadgetclass ?
Have you ever heard of BGUI? Are you aware of the latest developments?
It happens that I am the BGUI maintainer. So, I am aware that those claims
that BOOPSI based gadgets can't be that complex are plain false. I am
disappointed about you, a well known skilled Amiga programmer, is
attempting to put down other GUI toolkits to favour MUI assuming that we
don't know better.
The discussion MUI vs. the world is useless when all the sides are not
willing to present unbiased views.
> It is not a coincidence, but caused by the fact that MUI, being a
> properly designed single-threaded system, is fully scalable,
> deadlock-free, and stable. ClassAct and BOOPSI/gadgetclass attempt
> to marry the concepts of OO and multi-threaded resource locking and,
> inevitably, run into brick walls and fail, as soon as the complexity
> of classes and class interactions exceeds certain thresholds. For the
> same reason you hardly ever see any "replacement classes" for existing
> BOOPSI/gadgetclass or ClassAct classes. Both systems break OO
> information hiding principles and make it impossible to cleanly and
> reliably replace (and sometimes even subclass) existing classes.
As I said before, classes that were never meant to be sub-classes before
being designed are not suitable for sub-classing. That has nothing to do
with multi-threading.
>I don't know if Stefan Stuntz actually realized the fundamental
>theoretical flaw in BOOPSI/gadgetclass, or if he only saw the smaller
>problems, or just did not like BOOPSI/gadgetclass. In any case, he
>did the Right Thing in making MUI single-threaded and throwing BOOPSI
>notification and gadgetclass out. That was the only way to design a
>system as complex as MUI and keep it stable. Most other successful GUI
>OO systems (e.g. Motif) do similar things. Those that try to be
>multi-threaded or distributed are usually so "experimental" as to be
>unusable. The only flaw I can see with the MUI model is that Stefan did
>not stress these points enough in his developer docs, and did not
>encourage developers sufficiently to create a proper run-time
>environment in applications (dedicated GUI event process etc.). Better
>documentation and some template functions would have gone a long way
>here...
What you are saying basically that Amiga OS should never have had the
intuition task to preprocess the GUI events so all applications have to
wait for intuition messages and process them in their CPU time if they ever
get enough.
If MUI approach was ever the best it would even have MUI gadgets to emulate
Intuition menus just like it does for buttons and other gadgets.
>Regarding the Java GUI OO model: You are wrong here as well. The Java
>GUI OO model does use multiple threads, but differently than
>input.device. AWT handled things further away from the application,
>like BOOPSI/gadgetclass, which is one of the reasons for its poor
>stability and performance. Swing was designed to move events closer
Maybe on systems that already handle GUI events on the application process.
AFAIK, we still don't have a working Amiga AWT based on BOOPSI gadgetclass
gadgets to make you see the obvious difference in performance.
>into the application space, similar to MUI. Whether you see any
>"apparent slowness" only depends on relative thread priorities in
>Java, not on the event schedule.
Everytime the application has to handle GUI events to update state imagery
it will always "look slow". Anybody that is not biased towards MUI will
reckon that "apparent slowness".
Regards,
Manuel Lemos
E-mail: [EMAIL PROTECTED]
URL: http://www.e-na.net/the_author.html
PGP key: finger:[EMAIL PROTECTED]
--
--
To unsubscribe send "unsubscribe daytona-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
