Apologies if this is supposedly obvious and I missed it but how can one enable opaque window moving and resizing? I was surprised to find out this was even possible since it is not enabled by default.

Do I need third party software?

In SYS:Tools/Commodities start the Opaque commodity

@ASiegel

Opaque commodity it allows you to move windows with their contents showing while it moves

To use it, simply click on the icon. For permanent use, copy the Opaque file and its icon to the WBStartup system folder.

Please note that Opaque does not work well. Some time ago, we reported a bug whereby graphic artefacts are generated when you resize windows.

@deadwood
Silly me was looking in Prefs. Thanks.

@AMIGASYSTEM
Ah, that's too bad. Still, thanks for the answer.

@AMIGASYSTEM

Are those artefacts happening on any video driver (VESA, VMWARE and Hosted) or just on one of them?

Yes, artefacts (see video) are present in VESA, VMWARE and Hosted.

These are not really artefacts. It's just side effect of slow re-painting.

AROS does not have compositing layers/windows like AOS4 or MOS or modern OSes.
Those always store the whole contents of windows in offscreen bitmap. Even parts that are hidden, like when occluded by other windows. This means that when the hidden/visible area of windows changes it can very quickly be repainted by blitting from that offscreen bitmap.

AROS still works like AOS3.x where typically many program windows are of "simple refresh" type. For MUI program that's the default too. Those don't remember anything about their hidden parts. Whenever a hidden part becomes visible again they get a refresh message and then must repaint manually. This can be slow. AROS itself is slow/unoptimized/unaccelerated in some gfx things. Color gradients for exmaple are or at least used to be slow.

The way the artefacts look in the video if also affected by MUI/Zune habit of using do-nothing backfill hook. This is actually an optimization. Normally when a hidden area of a window becomes visible, it is first cleared/filled by a backfill (default color 0 = grey) by layers.library. And after that the program repaints. If a program repaints each and every pixel anyway this is waste of time, so one can use (and Zune/MUI does) do-nothing backfill hook. The side effect is that (if repainting is slow) you can see a dpaint-brushpaint-like effect where a foreground window seems to leave behind trails of itself (or it's window border) in the windows behind.

Wait ... I tried myself and there does seem to be something wrong. With wanderer/iconview/whatever lagging repaint or whatever. In some (very) old AROS (hosted) build that I have laying around it does not happen. Opaque resizing Commodities drawer is very fast and smooth and not much repaint lag at all.

With never AROS build it does happen but not with every drawer window.

Okay, I think what's happening is that icons are being loaded/freed all the time during window resizing.
During window resizing MUI/Zune does MUIM_Hide and then MUIM_Show.

In older AROS sources I have lying around this icon loading/freeing was done in MUIM_Setup/MUIM_Cleanup.

There's a commit to "workbench/system/Wanderer/Classes/iconlist.c" from 2019 which says "_screen is only valid between show/hide.". That's wrong. Changes in it seem to have moved stuff around from setup/cleanup into show/hide.

What I find interesting is what happens when you resize the Odyssey window. This is arguably a relatively heavy app. While the window decorations flicker rather prominently, the Cairo viewport is quite stable as there is really no tearing or flickering to speak of.