Layers.library V45 on the aminet

[itix]

Besides a major cleanup of the Os 3.1 version of layers (v40), the optimizations for graphic cards and the improvements in memory management, this release also provides new functionalities to hide and show layers, for example to allow window iconification with little or no extra efford from software.

This is not real iconification. Hiding layer leaves screen locked preventing Workbench theme and screen resolution changes. It is useful to hide layer temporarily without disposing window but to support real iconification it should always use screennotify.library and CloseWindow() on demand.

Real iconification requires quite lot effort but is worth of it. It is quite bad when Workbench is complaining it cant adjust screen and asks user to close all windows but user cant see any.

[itix]

Which is, of course, quite impossible for applications that have not written with this use in mind.

It is not impossible. It takes some effort and no effort at all if you use some high level frame work. Using low level Intuition calls is deprecated anyway... nobody should be using Intuition window calls directly in this century.

You probably don't understand the vision here: What it requires is an update of intuition and workbench to allow closing the WB screen *with hidden windows* on it. This is "in principle" no problem because the full window content is in the backing store in first place, so it can be re-rendered when necessary. Of course, lots and lots of things would need to be done for that, not saying that I would do that - I wouldn't. Like conversion between bitdepths (and conversion between screen organizations, but that's something rtg implements anyhow). But a first step needs to be taken, and it is practical to have this limited feature in first place.    Then un-hide the windows in that case as a first step... (-:

No I dont understand this functionality that encourages developers to not develop properly functioning software. It is bad design.

Nobody is going to update Intuition. Not you, not anyone else.

It really makes no sense to request from existing programs that have not been designed with this application in mind to iconify themselves. As you say, it is a *lot* of work. ViNCEd, the 3.9 console, can do that. For that, it has its own "backing store" of the editor contents (ViNCEd is an editor), and it can even make shell output, scrolling, and control sequence handling without any type of window attached to it. It delivers screen sizes, cursor positions and everything to every program running in it. You can iconify the Shell with "list" running in it, and restore it later, seing the "list" being done and complete, it does not stop programs for being iconified (unlike the "ape shell" or whatever its name was).

That is not much. Pretty common in every Amiga shell I have seen in this century.

But, remembering how much work this little feature was, just to get everything worked out correctly, I cannot realistically request that from any arbitrary application. It is the wrong way around. The Os needs to ensure that applications can render themselves to their windows, even if the windows are not "phyically attached" to any display. This is precisely the core functionality of what "HideLayer" does. Well, in essence. There are a couple of corner cases that would require a solution, but that's where the development should have gone should I have had more time and a working hardware to get things done back then.  It's all too late now, but you got what you got, and that's better than nothing.

Trivial.

[itix]

I don't know why you should. I'm making an offer. Probably you start with the Readme, because it answers a couple of questions what is wrong with V40 layers.

To keep it very short, besides the new functions, it is much more efficient when depth-arringing windows. V40 had an algorithm that scaled like O(n^2) in the number of overlapping windows, V45 is only O(n). Given CPU driven memory copies in some situations on rtg, this makes a noticable difference.

That should give huge boost. Even on some vanilla A1200 if you had ten overlapping windows it was already crawling.

Btw is there still noticeable speed penalty when rendering to non-overlapped window that is not the top most one? That was another issue with the original layer code...

[itix]

Apparently, you want to troll. Ok, you want it, you get it: Tell me how you can iconify a window of a program you don't have the sources for. There is no "framework" for this. There is only the binary. Actually, most Amiga programs are like that.

Of course those programs cant be fixed. I guess AmiSnip is some kind of commodity that can hide windows and inserts them to tools menu? It is perfectly OK. Applications having built-in faked iconify with HideLayers() is not. I just wouldnt want see anyone using it on new code.

Just in case you did not notice: Nobody uses the Amiga in this century anyhow. Nobody writes new programs in this century anyhow. The majority of programs available for Amiga uses intuition and not a fancy framework. Which of the dozends of incompatible frameworks should I pick today, given that none of them is an integrated part of the Os?    There are no encouraged developers left - just to remind you. Nobody will rewrite old software.

I dont know any incompatible frameworks.

Some frameworks do better than others but no any developer should be encouraged to use low level Intuition anymore. It is rude environment and crash prone if you make even small mistake. It was good in 80s but not anymore.

And no, it is not bad design. It keeps the existing functions working in a completely solid way, using the existing functionalities, even in a pretty trivial way.    Wisely said.

I have got enough with software that cant go away when I am adjusting Workbench screen. It is annoying especially if there is no visual clue which programs are preventing that.

If things are so trivial, I suggest you start rewriting the old applications using the new fancy frameworks. I wish you luck getting sources and redesigning software made over the last years.

I have done that couple of times. SnoopDos, Frodo and some text adventure game I cant remember right now. It takes some effort but can be worth of it as in result you can throw away old mumbo jumbo. Basically that is all low level stuff to manage windows, IDCMP ports, gadget definitions and many more I cant remember anymore. They take lot space in code yet there is only very rudimentary UI layout that is neither user or developer friendly.

Agreed we dont have developers left. If we had many old software could be modernized and often with relatively little effort.

[itix]

I know too many. Let's see... MUI, Triton, Reaction,... I believe there were a lot more. One looks different from the other, user experience differs...

Okay I see what you mean by incompatible frameworks.

CBMs investment into establishing a higher abstraction layer on top of the intuition primitives came too late (boopsis) and offered too little. Do programs have a consistent L&F? Not beyond what intuition offers as standard L&F, namely window decorations and system boopsis. And no, thank you, I do not need another framework for another feature you can get independent of frameworks.  So what do you encourage to use? There is no established standard framework.

MUI is de facto standard. It has standard L&F if you like. If you dont then MUI programs dont have same L&F with Gadtools or Intuition BOOPSI classes but it is up to user.

If you dont like it then maybe ClassAct.

And before I make my programs depend on a several 100K framework, or risk license incompatibilities, I'd rather stick with intuition.

Instead you reinvent wheel and reimplement 100K framework to your application. Which is fine, memory is cheap. But my time is not cheap and I prefer to take any shortcut where possible.

Yes, that's "back to the 80th", but Amiga *is* the 80ths. Nobody will change this anymore.  Actually, that's a design problem intuition has, and the mentioned V45 was a first step around that. Not a solution. Anyhow, I don't think it is was a very serious problem since I rarely changed the resolution or bit-depth of the workbench.

I dont want my Amiga to look like 80s. I have Amiga 500 for that and is perfect for that task. I still have warm feeling when I see Kickstart 1.3 console prints. But for other purposes I want something better. It is good hobby still.

I recall there are many other occasions where Workbench tried to close its screen. But it is not important in this discussion.

Given the many design problems AmigaOs has, it is actually not a very serious problem. There are definitely more serious ones. The bigger mess is actually gfx.

Is it really so? It is little messy but from developer POV not too messy. To draw graphics primitives (in RTG) you use two different libraries (GFX and CGX API) and sometimes you mix it with some layers.library call to allocate clipped rastports. It is not very clean but as long as developer knows what functions to call it works well enough.

Internally it is bigger mess (in AmigaOS 3) where RTG subsystem must patch system. But that is not so much concern to developers.

[itix]

MUI never worked for me. It's license-incompatible. To remind you, I wrote freeware. Pay-nothing. If I would use it, users would have had to pay for the interface, but not for the software. Pay somebody else for my programs? I beg your pardon.

I dont have problem with that because I am also getting an advantage: I can write UI faster with MUI than without MUI.

Anyhow, MUI doesn't solve the problem either. Consider a program that draws on the screen itself, preparing some kind of graphics. For the sake of the argument, consider your average Mandelbrot fractal generator. Now, how do you iconify this? Ok, you can create your *own* off-screen buffer and let the program render into that, and then always copy to the screen whenever there is one. But that's actually complete overshoot, and it also doubles the required resources. If you have a smartrefresh window, or even a superbitmap, this backing-store is already there, and transparently provided by the Os. So why not use it for exactly that, namely backing store while the window is not shown?

I would use off screen buffer in *fast ram*. RAM is cheap and everyone is having more fast ram than chip/video ram. Rendering to fast ram is also going to be faster than into chip/video ram. Another advantage is you can have re-sizable window.

Never did that. Gadtools worked nicely. Of course, that's fairly simple, but it was good enough for most cases. There was no need to go for the full-fledged 100K for MUI if I had everything I ever needed in ROM.

But how do you implement font sensitive UI with Gadtools without writing your own layout manager? You have to find out current font (coding), then calculate gadget sizes and positions (more coding) and then finally open GUI and add gadgets. Then you must write your own event loop and add keyboard handling for shortcuts.

As in? There is actually only a single Os call to do that. It could be called by programs that felt like it - in the beginning to save precious chip-ram - or for games to avoid screen-switching. Or to adjust the screen mode. It's non-crucial for the first applications since the memory situation improved. The latter is where it makes a difference, but this is typically not anoying since you do not adjust your screen every minute.

If you change fonts it has to reopen WB screen. I dont know why but tuning AOS used to be my favorite hobby in the past.

The purpose of iconification is not so much to get rid of the workbench, but to get a better overview on what's on the screen, and re-organize the windows. As soon as you have a couple of windows open, it becomes rather anoying to shuffle them around, and iconification is a solution.

I agree.

Yes, it really is. Its entire design is too tightly coupled to the Amiga chipset (bitplanes, blitting) and hard to abstract from. A lot of code in P96 is just there to emulate the bitmap blitting. Gfx also documented too many of its internals and does not have a clean interface. So for example, the view and the viewport are entirely "open" structures, which led to the bizarre hack that gfx stores the monitor and viewmode information in the *colormap* because this one was *not* documented. And uses hacks like "GfxAssociate" to link external published structures that can be messed with by any user by its internal administration structures, simply because the documented structures became too small and unsuitable.

The entire monitor database is an extreme hack and has no clearly documented structure. Instead, it depends on a couple of Gfx-internal databases that were never documented.

Oh, I see. But it was also typical for that era.

Instead of using clearly defined "creation and destruction" functions like intuition does (OpenWindow/CloseWindow) - nowadays one would call this "constructors" and "destructors", gfx relies upon the user that he builds such structures "correctly", which is a nightmare for forwards compatibility - see above: Such structures cannot be extended.

Count for example the number of patches that go into gfx to make rtg happen - an entire hack-o-rama necessary for graphics cards, with a lot of emulation overhead due to the poor interface.

Ok, seriously: Gfx was slammed together, probably in a rush, without thinking and without any design. It's an excellent example for teaching people of how *not* to design a graphics primitives library.

When I am reading RKRM gfx part I am getting impression GFX was meant to be low level interface to game developers. It does go in detail how to load views or build copper lists. It explains BOBs and sprites and there are dual playfield examples.

Some of examples in RKRM are not even safe because they bypass Intuition. Which is weird.

[itix]

So by increasing the stack footprint, you have cut down on memory allocations.

Theoretically any program that use this function can run out of stack, because many programs have small $STACK cookie, and default stack for shell commands and wb icons on Amiga is low to begin with.

They dont. There are many more OS calls consuming lot more stack and developers are adviced to not cut their stack size too small. The default stack size 4096 bytes is more than enough to most applications and stack command in the shell or WB icon setting dont have any effect to subtasks/processes anyway.

@modrobert

I've heard so many stories about how well C compilers optimize these days and how assembler is made redundant, and then when you actually disassemble the code the compiler produced, it's bloated, filled with jump tables, and inefficient code.

When you have 68020 or better it becomes irrelevant. On 68000 it can be noticeable, event without a stopwatch, but when it comes to Region functions in graphics library it becomes irrelevant again. If performance is problem you dont probably want to hand optimize Region calls but find better algorithm with O(n) or O(1) processing time.

[itix]

I think what Cosmos does right now is he looks at the compiler generated ASM output
and then figures that there are 10 instructions - which a smart coder could rewrite doen to 6.
And then he does this.
While this is cool and great - I wonder what would happen if he would not change this one routine -
but change the compiler to in the future see and use such optimizations.
Could this work? And how would the gain be if one would then recompile A-OS or AROS with the tuned compiler?

I dont think we are going to see AOS recompiled ever again. It is irreversibly sucked to a black hole.

And I don't think he has interest to that anyway.

But if it has to be done in 68k asm then it would be better rewrite intuition library in machine language only. Being rewrite rather than being based on disassembled binary you can open source this project.

[itix]

Huh? Been there, done that (1999). OS4 is based upon that work.

That is 15 years ago. I don't think we are going to see new 68k release. Only that matters to people here.

[itix]

If you can find somebody to pay for that, then the current owner of the operating system may actually want to sell it, if asked.

This is the black hole I mean. There is nobody to invest this money and then this current owner, whatever company it is. Re-establishing OS3 development would help MorphOS and AROS but makers of that another OS what I dont mention here surely wont agree.

[itix]

FFS is *not* slow. Ok, it is slow in *one particular* discipline, and that's listing of directories.

It has been more than 15 years when I used FFS but I recall it had another deficiency: it is slow at seeking large files. This became problem when first Doom ports appeared to Amiga and their WADs were relatively large. This of course was not problem at design time when harddisks were small but expensive.

Other filing systems use more complex directory structures, with the benefit of making directory reading faster, but making file manipulation slower.

Which is not necessarily what user deem important. Slow directory reading is immediately visible to the user. User can see it, he can measure it with his wris%&$#?@!%&$#?@!%&$#?@!%&$#?@!ch. Faster opening or reading of files, I am not sure if user observes that.

But it should be also mentioned that part of slowness was due to how directory scanning had to be done in the software. Scanning had to go through ExNext() loop and number of context switches and DOS packet traffic between scanning task and fs task. ExAll() solved this (when directly supported by the fs) although it is bit hack.

Edit: haha, wris%&$#?@!%&$#?@!%&$#?@!%&$#?@!ch == w r i s t w a t c h

[itix]

Yes, higher level languages are easier for most things.

Not yet, but define complex, or better yet, give some concrete examples of what creates the kind of complexity that is so hard to manage in assembly language (for software that would run well on 68020/30).

For anything that's worth implementing on 68020/30 certainly.

I have an idea: write a web browser. Such thing can run reasonably well on 68020 and is always useful.

I dont mind if you skip development phase and disassemble existing IBrowse 2.4 and just add CSS support.

[itix]

For me, learning from books is a mistake : the better and best way is to learn by yourself.

Start learning with tiny programms, understand how they works, modify them...

Your coding skills get better when you see fancy constructs but theory is still important. From books you can learn new algorithms, coding practises, development models, optimization (famous big O) and anything that helps to write better code in any language.

I used to be asm coder like you but when I had my first optimization class at uni I realized I had done it wrong. I was looking at details when I should have looked at the bigger picture.

[itix]

"Some of the states regulate the use of terms such as "computer engineer" and even "software engineer". These states include at least Texas[30] and Florida.[31] Texas even goes so far as to ban anyone from writing any real-time code without an engineering license"

That is quite funny to is Finns. Here in Finland title is (usually) used to describe your job than competence. It has gone ven so far that I can craft my job title if I want to. And sometimes i do. So far I have been Software engineer, embedded engineer, project engineer, research engineer, training engineer, development engineer and it could be anything relating to my work.

[itix]

Yes, it's why we have sandwich artists and kitchen technicians.
 
 The job title you have is largely irrelevant, I'd rather have more money than a flashier title (some companies stroke your ego with a flashy title just so they can pay you less)

I have been told that in India if you don't get promoted regularly employees quit. So companies have invented different levels of engineers, like level 1, 2, 3 etc software engineers to keep workers happy.