jcm

> and repeats the action ever couple seconds that the button is active Reading this original report a bit more thoroughly, I'm having a hard time imagining that this behavior...

This should be closeable now that the build system/CI has been updated to use the latest version of [apple-actions/import-codesign-certs@v3](https://github.com/Apple-Actions/import-codesign-certs) to import the certificate, and signing happens via `xcodebuild`.

I do not have the same issue under KDE in Fedora 41, however I am running under XWayland, while perhaps what you're seeing is the behavior under Xorg? 

Yeah, the reason this is still in draft is that I started working on a larger PR to allow all the software rendering functions in `screen` to be overridden optionally...

With the Metal implementation in this version, for mixed content with pixel widths of 256 and 320, the buffers would be scaled horizontally before shader passes at all times, not...

Without this PR the Metal backend takes in the 1280-wide buffer and passes that to librashader, which renders it onto an offscreen texture the same size as the final viewport,...

https://github.com/ares-emulator/ares/issues/1827#issuecomment-2654444660 Can confirm here that MoltenVK 1.2.9 (built on macOS 13 with Xcode 14.0 targeting macOS 10.13) crashes at runtime on macOS 10.14.6.

That seems to be correct. 1.2.8 also seems to have [the same issue](https://github.com/jcm93/ares-deps-2/actions/runs/13298924679/job/37136666463#step:7:855); 1.2.7 seems to be the latest version that can actually target 10.13.

It also seems like 1.2.7 crashes at runtime on 10.14, at least when using ParaLLEl-RDP and converting certain SPIRV to MSL. The details are in the linked issue thread in...

Yeah, seems like something along these lines: If I forcibly disable all Metal frame capture in the Scheme (by setting "GPU Frame Capture" to "Disabled") the runaway memory use stops....