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