Kalamatee Fixed a long standing SMP bug that cause it to crash after 16 Cores/Threads. AROS SMP Booting on 32C/64T CPU. :) [url=https://postimg.cc/wRQjQdb6][img]https://i.postimg.cc/wRQjQdb6/image.png[/img][/url]

Tiny Aros is like the Amiga Workbench after a clean installation: it has the bare minimum and is created according to what I know how to do. I hope it can be useful to you:)

Tiny Aros x86_64v11 v1.2 [URL=https://www.imagevenue.com/ME1BU51L][IMG]https://cdn-thumbs.imagevenue.com/c4/b2/ed/ME1BU51L_t.png[/IMG][/URL] Build AROS ABIv11 20250418-1-U2 Software Update: WCS BeeBase Protrekkr Lha Software MCAmiga OWB AmiTube MuiMapparium MPlayer ZuneView ArosPDF ZuneCalc ZunePaint Hex_2 Legadon AddStuff WhatIFF Magazine Pictures Demos

Hi, Michal Schulz now on about Emu68 having PowerPC and Pi-storm https://www.youtube.com/watch?v=7kPOZ6SKwCo Just ended

I'm not an AROS developer, but I'll be there to enjoy the event and meet people (like on Amiga 30). BTW, I had a lapsus before: I'll NOT be at the Amiga Party, rather to the SetPatch 2.0.

Well I will be there so if you are an AROS developer come and chat, if just a fan say Hi too. Steve

I'll be there (with My daughter), both days and in the Amiga Party as well, floating around...

I will be there, mostly at Alinea booth (I am not really an AROS user though, but AROS since recently is one of the Amigaoid platforms I ALSO support - mostly RetroArch stuff currently). RetroArch will be available at the Alinea booth (on a "mixed CD" - a bit like decades ago the Fish discs or whatever ^^ - which contains various ports by me for OS4/OS3 68k/OS3 WarpOS/MorphOS/AROS - AROS "only" RetroArch).

Good to see you back Steve :) For anyone who can't attend, there is going to be live stream of both days, more information here: [url]https://www.amiga-news.de/en/news/AN-2025-10-00070-EN.html[/url]

Welcome back Steve! Good to see you coming back AROS 'world' (no pun intended). You are always welcome to support AROS and yes it does make sense :)

Hi all I know I have been a ghost, sorry for that but priorities stopped my support work. Any way I will be doing a talk on Sunday and will discuss how I want to continue my support of AROS if I can and it makes sense. So I will be staying in Fire and Ice if any one wants to say hi. Steve Jones

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.

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.

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.

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.

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

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

@Deadwood Silly me was looking in Prefs. Thanks. @AMIGASYSTEM Ah, that's too bad. Still, thanks for the answer.

@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.

In SYS:Tools/Commodities start the Opaque commodity :)