academic technical discussion around the flaws

[Gorf]

Allright:
Let's talk about the flaws of AmigaOS's native GUI and GFX-system.
And how one would do it "the right way"

Originally Posted by bloodline

I've always thought that the graphics.library was a mess! It's reassuring to know I'm not the only one.

I never really understood the relationship between layers, graphics, and intuition, they all seem like parts of something bigger arbitrarily split out in to essentially random components.
I would love to have an academic technical discussion around the flaws and how things might have been implemented properly (if anyone else would find such a thought experiment fun?). Though that would probably be best in the System sub forum, not this hardware one.

Thomas mentioned Apples QuickDraw, PICT format and "resources" as a well designed example.

I would like to mention the "Enlightenment Foundation Libraries" as an inspiration:
https://www.enlightenment.org/about-efl

As well as a modern "immediate" approach:
https://github.com/Immediate-Mode-UI/Nuklear

Also there is the idea of having a completely scripted GUI (on top of some graphics-library):
TecUI (takes Lua scrips and is written in Lua itself)
http://tekui.neoscientists.org/screenshots.html
The elements use message passing via a module called "Exec"

While TecUI is stagnating since 2015, there is a similar but active approach:
https://luapower.com/ui

Pleas take these links as food for thoughts and not as "this is the right way".

What do you think?

[Thomas Richter]

For starters, I believe it would be overdue to clean up graphics. It is mostly a collection of graphical toolkit functions, just thrown on a big pile. Instead, graphics should be separated in multiple smaller libraries, probably with graphics just acting as a dispatcher into them.

We currently have:

DisplayInfoDataBase functions (originally in the "d" directory of graphics): These are functions to query, retrieve and build the display info database. Unfortunately, good functions to create them from outside, i.e. the stuff the "Monitor drivers" do, are missing, so it is currently all manual work (I wrote a documentation about that you find in aminet).

Blitter functions: This is all BltBitMap and friends. Currently, this is a patch orgy for P96. Instead, the graphics.library should just act as a dispatcher, check the bitmap, and then either forward to the native graphics system (probably "blitter.resouce") and an external system (e.g. P96).

Copper functions: This is roughly view and viewport related, split pretty randomly over the "c" and "a" directories, patched up in multiple ways. That is to some degree already abstracted through the mystical "VecInfo" of the display info database.

Region functions: For some reason completely unclear to me, this is pretty much a duplicate of layers, just that it operates on region and region rectangles rather than cliprects. This should probably go into layers instead.

The gels system: This is a mostly obsolete system for moving objects, bobs and vsprites,and animobjs. A small subset of the system is used by the workbench, and unfortunately it also pokes the blitter directly. This requires better abstraction such that P96 can hook into it in a better way. Unfortunately, it is also coupled into the copper system. This should really go into a separate library ("gels.library"?) where it would be (hopefully) forgotten. AnimObjs and AnimComps have several defects even as of today.

The text system: This is "Text", "TextExtend" "ScalerDiv" and related. Everything that is in the "text" directory of original graphics. As it just sits on top of BltTemplate(), it is already fit for RTG. It should be just a separate library.

[Bruce Abbott]

Originally Posted by Thomas Richter

For starters, I believe it would be overdue to clean up graphics.

Why?

[NorthWay]

I'd say there is one more factor to this mix: Printers.
In an ideal world you would be able to have something draw to your screen just as well as to a printer without handling it much differently, and it would look the best of what each device could produce.

Possibly a very tough sell for a poor 68000. I don't know if this could have been engineered with some additional layers that routed between a monitor or a printer instance.
For wishlist features I would have liked to see a fully program-operated (scriptable) GUI so that a different program could act as a robot and operate it, and possible another layer of abstractions so you could run remote programs (that was probably not even on the ideas list back then).

[Thomas Richter]

Originally Posted by Bruce Abbott

Why?

Because.

[Thomas Richter]

Originally Posted by NorthWay

I'd say there is one more factor to this mix: Printers.
In an ideal world you would be able to have something draw to your screen just as well as to a printer without handling it much differently, and it would look the best of what each device could produce.

NeXT had DisplayPostscript for that. If it's just graphics, we can also use postscript for it. I wouldn't base a GUI system on it because that's probably a bit too much for a poor Amiga.


I had something like this. It was called the "plotter.device" and could perform line and vector graphics on a printer and on the screen. It came with a Plotter-Handler where you could issue commands that were approximately equivalent to hpgl, the hp plotter language.


I never published it. The whole idea became obsoleted by the arrival of postscript.

Originally Posted by NorthWay

For wishlist features I would have liked to see a fully program-operated (scriptable) GUI so that a different program could act as a robot and operate it, and possible another layer of abstractions so you could run remote programs (that was probably not even on the ideas list back then).

reaction was going in this direction. The reaction.library took an abstract description of a GUI and created the class list from it, at run time. The reaction.library was part of 3.9, but I'm not sure whether anyone but H&P used it. I know next to nothing about it, and what I do not like about it is that it required a separate file to describe the GUI, so you couldn't generate self-contained binaries.

[kamelito]

IIRC in the 30th Amiga anniversary Peter Cherna said that Intuition is a mess.

[Thomas Richter]

Intuition is complex, surprisingly complex, but not a mess. Unlike graphics, it has a design and works on a couple of principles. The problem is its complex state machine - the user can change the state of GUI elements, the program can, through a different channel, the operations happen asynchronously, so the state can change while another state change is performed. That makes the whole design really "touchy".

[kamelito]

Is it possible to improve the design of those library while maintaining compatibility? Using wrappers for olds ones and let new programs use new libs?

[Thomas Richter]

Graphics, you mean? Well, that is at least "a lot of work", but of course the goal would be to have compatibility. My idea would be to have graphics simply as a dispatcher, i.e. as a forward call to other libraries or functions. For example, if BltBitMap is called, graphics would check the type of the bitmap, and forward that either to the "native" blitter.resource, or to a third-party package registered to a particular bitmap type. This would allow a "vendor neutral" extension.

Whether this will happen anytime.... I do not know.

[Gorf]

Originally Posted by Thomas Richter

NeXT had DisplayPostscript for that. If it's just graphics, we can also use postscript for it. I wouldn't base a GUI system on it because that's probably a bit too much for a poor Amiga.

Sun had NeWS in the late 80s early 90s, which is also Postscript based:

http://starynkevitch.net/Basile/NeWS..._oct_1993.html

On top of NeWS there was a GUI called HyperLook:

http://www.art.net/studios/Hackers/H...ook/index.html

And here is SimCity for Hyperlook :

http://www.art.net/studios/Hackers/H...look-demo.html

I had something like this. It was called the "plotter.device" and could perform line and vector graphics on a printer and on the screen. It came with a Plotter-Handler where you could issue commands that were approximately equivalent to hpgl, the hp plotter language.

I never published it. The whole idea became obsoleted by the arrival of postscript.

well - I would consider printers pretty much obsolete now ... at least for me.
But with modern display resolutions it does not matter anyways: you can use the same rasterization ...

Meaning: we probably should not limit ourselves by trying to provide some printer compatibility at this point...

reaction was going in this direction. The reaction.library took an abstract description of a GUI and created the class list from it, at run time. The reaction.library was part of 3.9, but I'm not sure whether anyone but H&P used it. I know next to nothing about it, and what I do not like about it is that it required a separate file to describe the GUI, so you couldn't generate self-contained binaries.

As said in the other thread: the amiga hunk format would should make it possible to create a joined binary for such things.

"Feelin" uses XML files for this:
https://www.feelin.fr

there is also XML for MUI

And there is of course the mostly forgotten GadOutline Library by Dianne Hackborn, that allows vector drawings in the GUI:
http://www.angryredplanet.com/~hackb...e/Example2.gif

[Minuous]

Originally Posted by Thomas Richter

The reaction.library was part of 3.9, but I'm not sure whether anyone but H&P used it. I know next to nothing about it, and what I do not like about it is that it required a separate file to describe the GUI, so you couldn't generate self-contained binaries.

I have some experience with resource.library, which is presumably what you are referring to. The GUI description is statically linked to the application binary, therefore the binary is fully self-contained.

[Bruce Abbott]

Originally Posted by Thomas Richter

Because.

That's what I thought. In my experience it's best to leave working code alone unless you have a good reason to change it. Apart from the satisfaction of making it 'tidier', what tangible benefits could there be to 'cleaning up' graphics library?

My idea would be to have graphics simply as a dispatcher, i.e. as a forward call to other libraries or functions. For example, if BltBitMap is called, graphics would check the type of the bitmap, and forward that either to the "native" blitter.resource, or to a third-party package registered to a particular bitmap type. This would allow a "vendor neutral" extension.

Sounds like a good idea. I have thought about hooking up a VGA card to my A500, but I don't know anything about how to drive it (through P96?). An official system interface would be nice.

[kamelito]

@Thor, graphics yep, I’d love to see a better animation system, should I say game library?

[Thomas Richter]

Originally Posted by Bruce Abbott

That's what I thought. In my experience it's best to leave working code alone unless you have a good reason to change it. Apart from the satisfaction of making it 'tidier', what tangible benefits could there be to 'cleaning up' graphics library?

The issue is maintainability. The current code is next to unmaintainable. Graphics is really special, it's build system is special (unlike other Os components).


The dos.library might be used weird, but with the intergration of arp into kick 2.0, CBM managed to get rid of the BCPL nightmare and brought the whole thing back into "some" shape. Not perfect, but a lot better than before.

[Bruce Abbott]

Originally Posted by Thomas Richter

The issue is maintainability. The current code is next to unmaintainable. Graphics is really special, it's build system is special (unlike other Os components).

What's special about it?

[bloodline]

Originally Posted by Bruce Abbott

What's special about it?

My guess would be there are issues related to how early it has to be brought up in the boot sequence, i.e. before Dos I assume.

[Thomas Richter]

Originally Posted by Bruce Abbott

What's special about it?

Every other Os component has a flat hierarchy - all files in one directory, and one make file. If an Os component becomes so big that its sources cannot be logically arranged in one directory, the component has a problem and should better be split up.

Graphics has a special build system. It comes in multiple directories (c,a,d,fonts,gels,text), and a hierarchical build system that, unlike other Os compoents, also does not attempt to resolve all dependencies automatically. Some directories had multiple make targets depending on the system: "a" created "aa.lib" or "ecs.lib" depending on the target system.

It was already hard to get this hierarchical system building correctly on vamos, and it is also hard to maintain (change one component, make clean, make - this takes probably 20 minutes on my system), but the need to have such a hierarchy should also give an indication that graphics is already "too big" and should be split up.

"d" is the display info database. This should be a separate library. "gels" is the 'junk' bobs,vsprites,animob,animcomp system almost nobody uses. It should be a separate library.

fonts is the text system, Text(), TextExtend(), and the default fonts. The default fonts (topaz.8 and topaz.9) should really be separate ROM modules. The text system should really be a separate library.

"a" and "c" are the graphics core system, but without much of a structure. "a" one should expect to contain only assembler sources, but that's only "mostly true", or "machine specific code", but that isn't true either (and less so in 3.1.4 where graphics was unified to support both AGA and ECS), and "c" should contain mostly C code, but that isn't true either.

The thing requires a major cleanup, really. Blitter functions ought to be factored out, such that RTG can customize them without a full patch-attack on entire graphics, bitmap handling should be factored out as well, for the same reason.

The display info database duplicates some of the structures of the "Monitor" system, and I really wonder why both exist in parallel - some information is stored in the monitor, some in the display info database, and there is no clear cut what belongs where.

Sprite resolution information: Same mess. Some parts are stored in the color map, others in the view port or monitor, general information in the display info database, but not in a way that allows clean customization to RTG.