HN Theater @HNTheaterMonth

⬐ orionblastar

The open source free clone of AmigaOS 3.X is AROS: https://aros.sourceforge.io/

It runs on many platforms. Even on an old PC.

⬐ Fjolsvith

AmiKit is an Amiga emulator that runs on many platforms also. The new version is purchase (29 euros), but the older version is pay what you want.

https://www.amikit.amiga.sk/

⬐ rasz

27 year from Commodore bankruptcy and no one fixed icons slowly loading one by one in Workbench. Freescale Dual core 2.0 GHz CPU, 2GB ram, pcie Radeon GPU .. and drawer takes 2 seconds to show contents.

⬐ obarthel

This is very hard to fix because the Workbench has to find every single icon file in a drawer, match it up against any drawers or files, then load the icon file and display it. There is no icon cache or, for that matter, no "these are the icons we last processed when we looked into this drawer" file.

Whenever you ask Workbench to show the contents of a drawer you are starting a full scan of that drawer's contents with Workbench picking up, one directory entry at a time, what it finds. Put another way, finding and displaying the icons is strongly I/O bound and limited by what the file system can deliver.

It has been like that since 1985/1986 and the fundamental architecture of Workbench has not changed since then. There is a large degree of freedom afforded by storing icons in individual files which impose no limitations on the size of the icons. You pay for that freedom by waiting for the icons to appear and the scanning finally finishing.

Fun fact, the original Workbench design in the Kickstart 1.x ROMs acknowledged that reading the directory entries of a drawer one at a time was too slow, especially on floppy disk. The solution to the problem was to create ".info" cache files which listed every entry which had an icon file associated with it. Workbench would read that file unless the parent drawer's "last changed" time stamp was more recent than the ".info" file's and thereby skip a lot of unnecessary directory scanning: it just had to read those icon files and be done with it. One small problem about that cache: the floppy disk file system scattered file data and metadata widely across the medium which as a by-product increased the effort of retrieving it.

⬐ rasz

> strongly I/O bound

Similar outcome with Ram Disk :). Its one thing to not display custom icons, its another to delay everything because you query for custom icons sequentially instead of displaying temporary ones.

⬐ obarthel

Falling back onto default icons is, arguably, just as tricky, if not more so.

Workbench cares about "real icons" because they are more likely to contain information relevant to the applications which created them (tool types, default tool, etc. are likely set to specific values). A default icon may be a convenient placeholder so that you may delete or rename the associated directory entry, but that may not be what matters to the user.

There is a side-effect in using default icons: they have to be placed in the drawer window so that they are visible and do not overlap with other icons. Workbench tries its best, but its internal data structures lean more towards memory usage efficiency than towards making non-overlapping icon placement efficient in terms of complexity and speed.

I would love to know about an algorithm which would render non-overlapping icon placement less complex and more efficient. The current implementation contributes its share to making directory processing slow. It scales poorly with the number of icons it has to check. This is why the "Show all files" view option is not particularly fast.

⬐ flohofwoe

Well one thing's for sure: the original AmigaOS UI theme in 3.2 has aged a lot better than the 4.1 neo-chrome theme which makes it look like a late-90's Linux distro (don't know though if 4.2 is themable, or whether this look is hardwired).