English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 06 January 2021, 18:34   #1
Gorf
Registered User

Gorf's Avatar
 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,304
academic technical discussion around the flaws

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


Quote:
Originally Posted by bloodline View Post
Quote:
Originally Posted by Thomas Richter View Post
Precisely, so they threw the thing together rather quickly, and lacked a clear perspective. This way, we have system components made by people that had good ideas and clear visions (exec, intuition), system components that were just collections of helper functions (graphics), some last-minute glue code (layers) that duplicates functions of graphics and intuition, and some hot-patched disk layer (Tripos). Or as Olaf put it: AmigaOs looks as if it is held together by several layers of glue, duct-tape and chewing gum. I can only agree.
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?
Gorf is online now  
Old 06 January 2021, 19:30   #2
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 977
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.
Thomas Richter is offline  
Old 06 January 2021, 22:42   #3
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 517
Quote:
Originally Posted by Thomas Richter View Post
For starters, I believe it would be overdue to clean up graphics.
Why?
Bruce Abbott is offline  
Old 07 January 2021, 15:58   #4
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 683
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).
NorthWay is offline  
Old 07 January 2021, 17:54   #5
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 977
Quote:
Originally Posted by Bruce Abbott View Post
Why?
Because.
Thomas Richter is offline  
Old 07 January 2021, 18:00   #6
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 977
Quote:
Originally Posted by NorthWay View Post
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.


Quote:
Originally Posted by NorthWay View Post
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.
Thomas Richter is offline  
Old 07 January 2021, 18:37   #7
kamelito
Zone Friend

kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,307
IIRC in the 30th Amiga anniversary Peter Cherna said that Intuition is a mess.
kamelito is offline  
Old 07 January 2021, 20:10   #8
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 977
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".
Thomas Richter is offline  
Old 07 January 2021, 22:12   #9
kamelito
Zone Friend

kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,307
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?
kamelito is offline  
Old 08 January 2021, 01:04   #10
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 977
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.
Thomas Richter is offline  
Old 08 January 2021, 01:25   #11
Gorf
Registered User

Gorf's Avatar
 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,304
Quote:
Originally Posted by Thomas Richter View Post
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

Quote:
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...


Quote:
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
Gorf is online now  
Old 08 January 2021, 01:41   #12
Minuous
Coder/webmaster/gamer
Minuous's Avatar
 
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,210
Quote:
Originally Posted by Thomas Richter View Post
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.
Minuous is offline  
Old 08 January 2021, 07:23   #13
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 517
Quote:
Originally Posted by Thomas Richter View Post
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?

Quote:
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.
Bruce Abbott is offline  
Old 08 January 2021, 11:35   #14
kamelito
Zone Friend

kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,307
@Thor, graphics yep, I’d love to see a better animation system, should I say game library?
kamelito is offline  
Old 08 January 2021, 16:25   #15
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 977
Quote:
Originally Posted by Bruce Abbott View Post
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.
Thomas Richter is offline  
Old 10 January 2021, 04:40   #16
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 517
Quote:
Originally Posted by Thomas Richter View Post
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?
Bruce Abbott is offline  
Old 10 January 2021, 17:03   #17
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 360
Quote:
Originally Posted by Bruce Abbott View Post
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.
bloodline is offline  
Old 20 February 2021, 13:13   #18
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 977
Quote:
Originally Posted by Bruce Abbott View Post
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.
Thomas Richter is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for technical manuals Leandro Jardim Retrogaming General Discussion 5 30 December 2012 16:36
WB technical question... nikvest support.Apps 6 16 April 2008 10:13
technical question about amigas gimbal Nostalgia & memories 1 09 November 2007 15:36
The Settlers - technical problems mr_a500 support.Games 5 10 January 2006 23:14
Stupid Technical Questions Shatterhand Retrogaming General Discussion 4 05 October 2001 06:33

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:36.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.08579 seconds with 15 queries