I’ve been thinking about whether AROS could gain a modern presentation layer without replacing Intuition or breaking compatibility with old software.

The idea is to keep Intuition responsible for windows, screens, focus, and input, but introduce a modern Surface / Buffer / Damage / Commit model underneath. Old applications could continue using RastPorts and existing APIs, while newer software could progressively use retained surfaces, HiDPI-aware rendering, GPU-backed buffers and eventually zero-copy presentation.

This is not mainly about transparency or visual effects. It is about creating a path from the classic Screen / Layer / RastPort model toward something that supports modern rendering, better frame presentation, damage tracking, HiDPI, games, and GPU-based applications, while still preserving the old path on legacy hardware.

I already have a small PoC: two normal Intuition windows on a composited screen. One draws its contents only once into a backing store, while the other can move over it at 60% opacity. The covered window remains intact with content draws: 1 and refresh events: 0.

So the goal is: modern surfaces and presentation underneath Intuition, without throwing away the Amiga model above it.

I haven't consulted anyone yet, and I built this only for my own leisure. I know there were views and attempts; I will check them out and poke people whom I already know to put some thought into the model. The demo itself is also nothing new in the Amiga world - both OS4 and MorphOS have composition. So for now it's more of a catch-up and architecture for the future.

The next step is per-pixel alpha and performance measurements, working toward a compositor that keeps existing Intuition applications and classic screens working. Keeping composition independent of the rendering backend would let us start with CPU rendering and add OpenGL or other accelerated backends later, without tying applications to a particular graphics API.

For regular users, this could mean smoother window movement, transparent desktop elements, and better scaling on modern displays. For developers, it would provide a consistent surface and presentation model for richer interfaces, without manually copying backgrounds or targeting a specific rendering backend.

Per-Pixel alpha:



For a quick and dirty experiment, I am quite optimistic: it can be done, which was pretty obvious, but it's still a yay. The performance is okay for the first try, but at 1080p it's already below usable. Still - no optimizations and tests are run on Mac in TCG mode, with other apps and tests running. I will measure later in more optimal situations.

If there would be anyone interested in measuring this on real hardware, I consider doing an iso image soon.

From someone like myself who does a lot of work intuition windows and rasterports this is very interesting!

Most of what I do involves using WritePixelArray & WritePixelArrayAlpha to render 24bit & 32bit images into a raterport. If there were an easier/better way to do it I'm open to that. Reading Alpha from the rasterport would be nice!

Great work! Thank you. I really like the transparent windows!

P.S. - It's nice to see improvement for appearances such as this. AROS also, in my opinion, could benefit from a more modern, easy to use GUI toolkit that is appealing to users.

Font selection and font rendering is another area that could use improvements.:-)

That's awesome stuff!!!

Thanks! Your workflow is exactly the kind of real application use case I’d like to test while keeping existing RastPort drawing working. One distinction is blending an image into a window versus retaining its alpha so the compositor can show what’s underneath—the PoC currently uses a separate alpha plane, so preserving and reading alpha through RastPort operations is a next step to explore, rather than something it supports yet.

MUI is not bad; it has many advantages and is - imho - a well-thought-out system, but AROS has quite a dated implementation -> Zune. And our problem is that there's no one (who I know) who feels confident in the art direction. I started extending Zune - I already did it with Folio, and I will make proposals for everyone to adopt. From this point, I would encourage everyone to do the same. We should also look towards other systems for inspiration, e.g., Qt, SwiftUI, and Haiku/BeOS. I think we could also learn a thing or two in general from the old Apple Human Interface Guidelines.

For fonts, I've already been working on this: Limpet uses HarfBuzz, while MarkEdit and my upcoming Tuesday app share a text engine built around cosmic-text, HarfRust for shaping, and swash for glyph rendering. Font selection and fallback are controlled through a shared font API. The idea is to make this reusable infrastructure for other AROS applications, rather than solve typography separately in every app. But I have doubts if the effort will pay off until we get support for high dpi screens.

Long story short:
Please share your use cases - that would be very helpful and we can work things out

There are a couple use cases I can provide for intuition enhancement.

I'd like to use a borderless, invisible window with just a rasterport to draw black text or gadgets/widgets. The window will be placed directly over the right side screen Titlebar. If the window were transparent and the Titlebar beneath shows through that's perfect. But if color matching and alpha blending is needed that's more work involved. That's how the DigiClock App works.

Second, one of my Icon Apps, Icon Builder displays an icon image then draws an RGB glow mask inside the rasterport. Since the original image has alpha values I have to use two byte arrays to figure out which pixels changed. Being able to read alpha values from the rasterport would be very helpful in that case.

Lastly, a Tool Window with no Titlebar or gadgets other than Close, just a Drag Bar slightly taller than the Close Gadget that can be set to AutoHide the gripper/drag bar. Tool Windows would be useful for Button Menus, Icon App Launchers, Paint Programs, etc.

For Zune, being able select a complete set of gadget artwork at once would be great instead of for each gadget separately. Maybe a few predefined artwork packages that defines the look of buttons, frames, radio buttons, check boxes, etc. "Zune Gadget Themes".

Just a few ideas.

To help clarify what I said previously, I know, I said a lot ;-)

Bring able to preserve the alpha values in the rasterport and being able to read the alpha values back would be a great improvement.

As for the Tool Window idea I can give some examples.

It would facilitate other visual enhancements such as borderless, invisible tool windows with just a small Drag Bar for Icon App Launchers (Icon Bars). Setting the Drag Bar to AutoHide makes it visible when the mouse hovers over it to allow repositioning the window. When dragging just show the Drag Bar, window contents (Icons) and an outline of the window. After dragging everything disappears except icons.

Being able to rotate the window would be helpful for vertical, horizontal alignment.

Another use case involves a borderless, transparent window that can be "Docked" on the bottom of the screen (Icon Dock).

If we can set the window background to completely transparent and still be able to draw RGB (opaque) pixels in the rasterport that should work.

Have you thought about transparent menus?

Don't get me wrong, but just to be clear: you’re mainly describing improvements to Intuition and Zune, which makes sense. What I’m building underneath is a compositor: each window keeps its own contents, and those surfaces combine with the screen background to produce the displayed image.

That provides the foundation for things like a transparent DigiClock or icon bar without copying the background. Alpha readback would need a drawing API extension; auto-hiding drag bars and docking would need Intuition work; gadget themes belong in Zune. Your examples are useful because they show how applications could use that foundation. But I understand - usually we talk and think of compositing window managers such as compiz or KWin. This is my plan to combine aros-composer with intuition but right now I'm working only on the foundation.

https://en.wikipe...p_Language
https://en.wikipe...Foundation

Ah. Ok. I understand.

It's not enhancements for intuition but rather something that works in conjunction with it.

I'm interested to see how it develops. Very nice project.

I assume you wanted to provide examples of different approaches to building user interfaces? Declarative UI would definitely be a good direction.

If I were to put together a wishlist of ideas for AROS worth borrowing, I'd pick:

- MUI: The control model, layout system, and user customization.
- WPF: Lookless controls, separating behavior from visual representation through templates, enabling consistent themes rather than a collection of independently drawn gadgets.
- Qt Quick: The scene graph and rendering architecture, separating the logical UI tree from its rendering representation and enabling GPU acceleration and efficient compositing.
- SwiftUI: Convenient declarative view definitions, state binding, and automatic UI updates when state changes.

In the context of AROS, I think the biggest architectural improvement would be separating Zune's control tree from its rendering tree. This would let us modernize rendering independently of existing APIs and gradually introduce more advanced capabilities.

Ideally, all of this would support progressive enhancement: existing applications should continue working, while newer ones could take advantage of modern rendering and UI capabilities.