@retrofaza Thanks, your log helped fix the Nouveau artifacts. EdgeSnap 0.3 now validates framebuffer reads before drawing and also fixes the seam colour.

Available here:
https://github.co...s/tag/v0.3

Also on Aminet and AROS Archives. Please report any remaining artifacts, especially the black drawer interiors, with a screenshot and driver details.

@AMIGASYSTEM Your icons are included and credited in the source, README and guide. Thank you!

It looks like the same artifacts are still occurring in Nouveau.
I'm attaching the log from the latest version.

@retrofaza That log was super helpful, thank you! It pinpointed the issue right away, on Nouveau drivers, reads work fine but writes don't (WritePixelArray), and my old check only tested reads while retrying on every drag which caused those visual trails.

I've fixed it in two ways:

It now does a quick write/read check in a tiny corner before rendering anything.
If it fails once, it disables itself immediately instead of retrying on every drag (touching a few pixels once, rather than glitching on every move). Working drivers are unaffected.
Here's a test build to try: https://drive.goo...sp=sharing
If the trails are gone, I'll put it straight into the next release! If not, please send the log again, the key thing to look for is whether "pixel reads not trusted" shows up on frame 1.

“pixel reads not trusted” appears in the log, but overall everything looks much better now—there are no traces left on the screen. (As you can see in the video, one pixel remained the first time, but once it was overwritten, no more remained.)

I'm attaching the log and the video so you can judge for yourself.

https://www.youtu...uau4euNqp8

The fix works, after the first frame, EdgeSnap automatically switches to color inversion (no more blue frame on Nouveau) and leaves no trails behind. This is going straight into 0.4.

If you have a minute for one last check (to see if that single stray pixel shows up without the Shell logging underneath):

text


SYS:WBStartup/EdgeSnap QUIT
Run >NIL: SYS:WBStartup/EdgeSnap >RAM:es.txt
Try it out, stop it with SYS:WBStartup/EdgeSnap QUIT, and send me RAM:es.txt.

Thanks again, your help made EdgeSnap so much better on real hardware!

@kaffeine

Black artifacts always appear when using DualPNG backgrounds and icons

@AMIGASYSTEM Thanks! I tested on AROS One 1.3: drawers stay clean here, but I did reproduce black bars in Shell windows after a snap (already fixing this for 0.4).

To track down your specific black glitch, could you check:

Does it happen in drawers, Shell windows, or both? (A screenshot would settle it).
Does it happen using hotkeys (Ctrl + Alt + Arrows)?
What graphics driver, screen mode/depth, and theme are you using?
Could you grab a quick log? Run this in a Shell:




(The Shell will stay busy and blank—this is normal. Snap a few windows until the black shows up, press Ctrl+C, and send me RAM:es.txt).
@retrofaza Quick correction: my previous Run command fails silently on AROS because of the double redirection.
Please use the command above instead (run it in a Shell, trigger the snap, stop with Ctrl+C, and send RAM:es.txt).

@kaffeine

I'm attaching a screenshot and the es.txt file.

But that's exactly how I conducted the last test, as you can see in the video. Unless, of course, you're talking about something else—in which case, I don't understand. If you could please explain in more detail what I should do differently, I'd appreciate it.

@AMIGASYSTEM The screenshot clearly shows the right side of the drawer staying black. The text file didn't make it through (the forum blocks .txt attachments), so could you please .zip es.txt or paste its text into a code block?

A few quick questions to help isolate it:

What environment are you running AROS One on? (If VirtualBox: which host OS, graphics controller like VBoxVGA/VBoxSVGA/VMSVGA, driver, screen mode, and color depth?)
If you drag another window over that black area and away, does it repaint properly?
Have you ever seen this happen without EdgeSnap (e.g. clicking a drawer's zoom gadget)?
I suspect a race condition: EdgeSnap asks Wanderer to repaint right after a snap, but if Wanderer hasn't finished resizing yet, it drops the request. I'm updating EdgeSnap to wait until Wanderer is completely done.

@retrofaza You're right, my mistake. Your last test already proved it: with nothing printing underneath, that single stray pixel on the first frame definitely comes from the driver. From frame 2 onward, EdgeSnap switches to color inversion and leaves nothing behind.
You're all set no further tests needed on your end. Thanks a ton for your patience.

@AMIGASYSTEM Your screenshot shows the drawer coming up only partly drawn, with its right part left black, I have tried hard to reproduce it here on AROS One 1.3, with the standard driver and with the VMware one, with Wanderer slowed down on purpose, and the drawers always come out clean. So the difference is in a setting.

Could you open Prefs/Zune, page Windows, and tell me what "Refresh" and "Redraw" say? Here they are "smart" and "without clear", which is what AROS One ships. In the Zune source, a window only gets Wanderer's own background painter when Redraw is "without clear"; with "with clear" every area a snap uncovers or adds is wiped to black until something repaints it, which is exactly what your picture looks like.

If yours says "with clear", could you set it to "without clear", press Save, close and reopen a drawer, and snap it again? If the black is gone we have found the cause, and I will make EdgeSnap cope with that setting too. The log would still help: the forum refuses .txt files, so please zip it or paste it in a code block.

@kaffeine
I've tried everything in Prefs/Zune, but the problem persists, both on VMware and on a native PC (VESA).
It could be the DualPNG icons, or it could be the wallpapers, I have no idea. We had the same problem with the “Opaque” commodity. I need to run some tests with a clean build.

As said MUIM_Draw handling in Wanderer classes is or may be broken. When it tries to do optimized resize-drawing. Try to comment out lines in those classes (workbench/system/Wanderer/Classes/*) that do "data->icld_UpdateMode = UPDATE_RESIZE".

@AMIGASYSTEM

Here is IconList.mui class changed according to @aros-sg suggestion.

@aros-sg

Here is diff (only iconlist.c, icon.c is not used). Is this change also supposed to fix issues visible with Opaque?

It doesn't solve the EdgeSnap issue or the Opaque issue either.

@AMIGASYSTEM Thank you for testing it so quickly. Three things would narrow it down a lot:

1. After copying the new IconList.mui, did you reboot? A class already in memory keeps being used until it is flushed; Version on the file in use should show deadwood's date.
2. Does the black appear when you resize or zoom a drawer by hand, with its own gadgets, with neither EdgeSnap nor Opaque running? If it does, the problem is entirely in Wanderer or Zune; if it does not, it is about a program moving and resizing a window.
3. In your screenshot the path bar is black too, and that gadget is not part of the icon list, which suggests the whole window is not being repainted rather than one class drawing too little.

To reproduce it here with your exact setup, could you zip and attach ENVARC:SYS/Wanderer/global.prefs and ENVARC:Zune/global.prefs, and tell me which theme and icon set you use? On AROS One 1.3 as it installs, with the same two drivers, I cannot make the drawers go black at all.

@AMIGASYSTEM - please also use a different Desktop then Wanderer - use Scalos or Magellan and see if you are getting the same issues.

I did not try the fix. I just remembered that some time ago (maybe even a year or two) someone on MorphOS forum said that Opaque Resizing of Wanderer Drawer windows was slow and I took a quick look after comparing a pretty old build of AROS (hosted) I had lying around with a newer (but not newest) one. The older one was much smoother. Turned out in the newer one during each and every window resize, all the icons were reloaded. Stuff in iconlist seems to have been moved from MUIM_Setup into MUIM_Show during "_screen is only valid between show/hide" commit which I'm pretty sure is wrong.

Before realising this I played around a lot with fast resizing of Wanderer Drawer windows with Opaque running. Doing that I noticed that I could quite easily produce artifacts (gfx of window border prop gadgets staying inside iconlist area, instead of being overpainted during redraw). To reproduce this open a drawer window and a shell window in front of it. Resize the shell window so it covers the middle of the drawer window. Then use the mouse to quickly and constantly resize the wanderer window. Sooner or later you should see the artifact.

In quick look at iconlist source I noticed the resize-optimization in MUIM_Draw. I did not do any tests, but knew that this is not safe because of how window actions like resizing are done by Intuition. They are done asynchronously. If a window is resized from width 200 to width 180 then at the time the program gets the NEWSIZE/CHANGEWINDOW msg and repaints the window, the window may already have experienced another resize. If a program (or MUI/Zune) reads window->Width|Height then this is only "true" at that exact moment. It's volatile. It can change any time. You may have gotten a NEWSIZE msg and now think the window width = 180. But a little bit later when you actually do the re-paint, the window may already have a different width like 150. So you (the repainter) think you have horizontally painted 180 worth of pixels, but some of it may have ended up in nirvana (clipped away, because window smaller). So if later window is resized again to 300 you may not have an area of 180 pixels wide already painted, but only 150.

@aros-sg

If you can provide me a patch, I'll integrate it and release update components. This problem with Opaque (and possibly this one with EdgeSnap) has gone unfixed a long time. I'm sure @AMIGASYSTEM would be happy with that fix.