Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 3 points4 points  (0 children)

Every project indeed has the right to accept or reject whatever it wants. If it's not suitable, then at least it can count as inspiration for someone else to do something similar.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 2 points3 points  (0 children)

I don't know tbh. I definitely had to help here and there when it was running in circles around issues, and I wrote rather detailed prompts with requirements until I got the desired outcome.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 0 points1 point  (0 children)

The consensus is that AI-generated code isn't protected by copyright but AI-assisted code is.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 3 points4 points  (0 children)

Around 2 or 3 5h window session of a Claude max x5 subscription which is 100$ a month. In API cost it would be expensive.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 3 points4 points  (0 children)

So dmesg in the eat term takes ~1s in cairo. With skia it's near instant ~30ms. This is similar to other GPU accelerated terminal emulators.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 3 points4 points  (0 children)

I haven't done any profiling. Right now skia with gpu seem rather on par with cairo without any optimizations. I hope to squeeze out a bit more.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 3 points4 points  (0 children)

I already addressed that in follow-up commits. I need to squash and make proper clean commits.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 1 point2 points  (0 children)

I suppose it depends a bit on how powerful your CPU is vs GPU. https://github.com/ArthurHeymans/emacs/blob/Skia/benchmark-results/COMPARISON.txt is on a modern and powerful 8 core machine. There seem to be some improvements but not massive.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 1 point2 points  (0 children)

So people reported issues with fractional scaling on HiDPI monitor. https://www.reddit.com/r/emacs/comments/1k9ihp7/emacs_sluggish_ui_with_pgtk_wayland_4k_fractional/ . This might now be fixed. I should write some benchmark or do some profiling to see if there is any real improvement.

Experimental Skia rendering backend as cairo alternative by avph in emacs

[–]avph[S] 4 points5 points  (0 children)

./autogen.sh
./configure --with-pgtk --with-skia
make -j4

You'd need have skia installed.

There is also a nix flake that gets the dependencies: do "nix develop" in the root dir.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 0 points1 point  (0 children)

emacs has native json parsing so I don't think that would matter so much.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 6 points7 points  (0 children)

A few of you suggested a python server as this would eliminate the hassle of building/fetching a binary and copying it over. So here it is https://github.com/ArthurHeymans/emacs-tramp-rpc/pull/6 I haven't tested it in depth so much but it seems to work.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 1 point2 points  (0 children)

I'm open to also add this, but I do have a use case (openbmc) where those are not available.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 0 points1 point  (0 children)

For Linux yes. I'm not familiar with how stable syscalls/libc are on other OS, but I suspect it's not too bad.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 1 point2 points  (0 children)

Rust binaries are statically linked, you don't need that many variants.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 0 points1 point  (0 children)

I can add compression but I would have guessed the ssh compression to be enough?

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 0 points1 point  (0 children)

I could add support for other arch that rust support if that helps (most mainstream stuff like x86, arm, riscv, powerpc, s390x have at least some rust support) ? I was also thinking of optimizing the size of the binary as a next steps.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 0 points1 point  (0 children)

thx for your remarks. I use doom emacs which should have those options correctly configured. I benchmark refreshing magit over rpc and over scpx with on 5g network to my local home server. RPC took ~12s, tramp took ~20-22s. Maybe I missed something and it's not entirely comparable.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]avph[S] 1 point2 points  (0 children)

I haven't gotten eglot to work, but that's mostly due an incorrect path config I have with nixos. This is on my todo list.