07-Feb-2023 18:04 GMT.
UNDER CONSTRUCTION
Anonymous, there are 105 items in your selection (but only 5 shown due to limitation) [1 - 50] [51 - 100] [101 - 105]
[Rant] AOS4 on AOne slow? Perhaps, perhaps not.ANN.lu
Posted on 23-Sep-2003 09:53 GMT by Fabio Alemagna105 comments
View flat
View list
Ok, I haven't had a chance to look at those videos until a few minutes ago, and I thought I'd give some reasons for which it appears slow, basign my judgments on what I see and what I know about the AmigaOS internals.

First of all, I must say that, although there was perhaps nothing more to see, those videos only show one little part of the GUI system, which, from what we know, could perhaps be the only one a bit flawed.

In essence, what we are shown are 2 things: the speed with which Reaction GUIs are drawn (in Solid-Resize and GUI-Reactivity), and the way (a faulty one - but read on) opaque window moving is implemented (in Opaque-Move).

Indeed, Reaction GUIs are drawn quite slowly, but I can't help but notice that Reaction GUIs have always been inherently slow, at least on my UAE setup, much slower than any other GUI, even MUI. The reason for this can be researched in the fact that Reaction uses a completely different approach than MUI, which is also the reason for which I greatly dislike Reaction in favour of MUI. However, it's obvious that the redraw is quite slow also considering Reaction's faults, and this is possibly due to the fact that the gfx library was emulated, along with a basic chipset support (some blitter thingies, like the BLTDONE flag in DMACONR register), which surely slowed everything down a lot.

Using this argument to say that AOS4 is at the same stage MOS was 2 years ago is pure flamebait for mainly 2 reasons: 2 years ago MOS already had a native gfx subsystem (which renders the comparision useless, although it might seem that it makes the situation even worse for AOS4), and also because this gfx subsystem is a temporary one, and we don't know at which state of development the new one is (but I reckon it's close to completion, or on the way to it). In any case, such comparisions are meaningless because AOS4 has now things which MOS didn't have 2 years ago, and vice versa.

About the opaque moving, instead, it can be noticed that there's a flaw in its implementation, which basically makes it *very hard* to *impossible* for the damaged windows to refresh themselves until the movement has stopped. Read Georg Steger's explanation of this phenomenon here

.
AOS4 on AOne slow? Perhaps, perhaps not. : Comment 101 of 105ANN.lu
Posted by Don Cox on 25-Sep-2003 15:14 GMT
In reply to Comment 98 (BrianK):
"The right tool for the right job is typically preferred. So, if I learn File --- Save that's the 'tool' for saving within an application. If I learn to cut with ctrl-v that's the 'tool' for cutting."

Normally, Appple-V or Amiga-V are for pasting, not cutting. However, these are keyboard standards, not GUI standards.

"The problem is with the consistency problem. If I want to cut and paste in one application why should I need to learn a different 'tool' (perhaps Amiga-Z) to cut? If I want to save why can I not use my file-save 'tool'? There are common pieces within applications that certain learned shortcuts and methods should be kept consistent."

Yes, those keyboard shortcuts should be standard - that is why it is a pity that Windows doesn't use the standard.

At least within a platform, the file requester, font requester and screen mode requester should be standard across programs.

But when you consider a GUI to suit a program - one may work best with the data enclosed inside window borders (Pagestream), another is better with the data covering the whole screen edge to edge (TVPaint), another is better with a grid of buttons and a smallish panel showing a render (Lightwave). usw.

On the Windows platform, compare Photoshop, Lightwave and Reason. Each has a completely different GUI, and two of them are good.
AOS4 on AOne slow? Perhaps, perhaps not. : Comment 102 of 105ANN.lu
Posted by Don Cox on 25-Sep-2003 15:20 GMT
In reply to Comment 100 (Joe "Floid" Kanowitz):
"On an unrelated note, this is actually where we get totally screwed; say you want DTP, do you use separate word processing and paint apps?"

My attitude to that is that writing, image creation/modification, and page layout are three separate tasks which would normally be done by different people. So when you fire up a DTP program, your text and image files should be ready for use, maybe on a CD sent in by the creators.

But it isn't cut and dried. Short texts such as captions can be typed in the DTP program.
AOS4 on AOne slow? Perhaps, perhaps not. : Comment 103 of 105ANN.lu
Posted by BrianK on 25-Sep-2003 16:31 GMT
In reply to Comment 102 (Don Cox):
Damn... Now I have to hire 2 more people to my one man shop.
AOS4 on AOne slow? Perhaps, perhaps not. : Comment 104 of 105ANN.lu
Posted by BrianK on 25-Sep-2003 16:40 GMT
In reply to Comment 101 (Don Cox):
"Normally, Appple-V or Amiga-V are for pasting, not cutting. However, these are keyboard standards, not GUI standards. "

Sorry, yes they are not GUI standards, UI standards.

"that is why it is a pity that Windows doesn't use the standard."

Windows, in the past, has been inconsistent on the use of it's 'standard'. Some programs have Edit-find some had search in other drop downs, and some have buttons. MSare getting OS and softwares more consistent as time progresses.

"But when you consider a GUI to suit a program"

The problem is GUI's shouldn't suit a program GUI's should suit the end-user of the system. You think that 2 of the 3 GUI's out of Photoshop, Lightwave and Reason are good. However, others may say all 3 are good or yet others may say that none are good.

My point is there are things that are common for all programs such as saving, opening, and printing that should have consistency. If you've something specialized like a palette for image editing OR a forumla maker for a spreadsheet then small specalized uses for those items may make better sense.
AOS4 on AOne slow? Perhaps, perhaps not. : Comment 105 of 105ANN.lu
Posted by Anonymous on 28-Sep-2003 19:58 GMT
In reply to Comment 34 (Fabio Alemagna):
Spending some time optimizing code you'll learn soon enough that even tiny losses often add up considerably. In this case there are several more issues and these tend to multiply the losses.
Anonymous, there are 105 items in your selection (but only 5 shown due to limitation) [1 - 50] [51 - 100] [101 - 105]
Back to Top