Currently gnome-shell is taking 135MB of ram, with other gdm/gnome related background services ranging in 700KB-3.2MB each to like 20MB together.
And it's as snappy as my sway config I log into depending on the needs.
I just spammed virtual desktop changes, opening Files, browsing, and it's as snappy as it is in sway.
I think gnome is getting a lot of unfair performance criticism online as it looks like something that would be slow.
Maybe it was slow back in the starting gnome3 days.
Maybe there are some heavy differences in how distros package it? (arch btw)
... though I will say that from my experience it's the KDE that's the slow one. I don't have it installed currently on this machine but had in the past and have it on my steam deck(which is stronger then this laptop).
It feels sluggish and I have this bouncing cursor wait animation in my head right now just thinking about it.
It's mostly on us, the developers.
Vulkan is fully supported on windows.
I would say that if you want to have multi-platform support just use Vulkan.
Covers most of the platforms(especially if you include MoltenVK)[0].
Though, for games, if you want to support Xbox, that usually throws a curveball into API choice planning. As that might be more important of a target than Linux/Android/Mac/iOS(maybe even combined) for your game. So if you already have to support DX for that..
I think saying that DX was first so it's Vulkan that was reinventing the wheel is incorrect with historical context.
AMD and DICE developed a prototype API called Mantle. Which is what both DX and Vulkan are based on.
Both Vulkan(glNext back then) and DX12 were announced around the same time. VK came a bit later as standards are usually slower in coming to decisions but it's not like VK was reinventing anything from DX.
I remember we were having a laugh reading early DX12 documentation as it was in parts just copied from Mantle with names unchanged in places!
I would guess that if DX didn't exist the iteration on VK side would just be faster. Through extensions, like you've mentioned.
In the end it might have even speed up the adoption of such features. Currently if you have a multiplatform engine, even though windows is like 99% of your PC player base it's still sometimes a tough decision to just use a feature that you can't support on all your targets.
But are you saying that compared to DX or just in general?
We're talking here about potential DX replacement, not about design in general and the bulk of it is very similar for both APIs.
There are some small quirks from Vulkan being made to be easily extensible which in the end I consider worth it.
I personally like how consistent the API is in both patterns and naming. After using it for a while, it's easy to infer what function will do from the name, how it will handle memory, and what you'll need to do with that object after the fact.
I think for Gamedev windows is mostly good just because that's where most of your players are.
Tooling was historically also better from a GUI perspective. With nicer to-use debuggers. Now on Linux you can use Jetbrains products if you need them.
Vulkan is just as much an industry standard as DirectX 12 is. I did a lot of work with both. Choosing between them is often just a matter of being already used to one when it comes to PC support.
You'll have to do DX for Xbox support and that's sometimes a bigger player base for you than Android/Linux/Switch/Mac(MoltenVK), though.
As a game developer, I can see how DX12 got a lead. As a Linux user, I'm a bit salty that it's being chosen so often! As we could have all united on an open multiplatform API :(
It's not ideal for me yet. I've had some problems with DAP. The DAP servers I've checked were a bit unstable and slow. For now I'm using gdb with nvim-gdb https://github.com/sakhnik/nvim-gdb
Very reliable and as fast as gdb is. But with all the problems just using gdb has.
If you're fine with dropping safety you can just make a wrapper around a raw pointer. I wouldn't do it in public library but if it's fine for your cpp code then it's fine for your rust code. You can always drop to the "blow my feet off" level.
It's pretty good. Epic added it as part of Unreal Engine to replace their previous hot reload system, which was more similar to the alternatives that people are mentioning here. That previous hot-reload didn't work as well as live coding, was less stable.
Simple dll reloading can work great if you separate state from logic, like shown in handmade hero. If you cannot enforce that then live++ is a good alternative.
I don't have this problem in practise. It's not "break flow to switch modes" for me. I don't type this way. There's always as much movement as there's typing, especially while programming. Even when writing prose I exit the insert mode each time I think of what to write next making this always a good "undo point".
If I make a typo while in the insert mode I just remove last character or last word. I guess you could argue that this is something that undo should also cover but I don't see much need for that.
I'm not in the insert mode, exiting to normal mode for movement and undo. I'm in the normal mode entering insert mode to write.
I never went back. But it still helped me for the standard tuning(mostly for playing other people songs).
When playing in standard tuning I see 6 string guitar as two parts a 4 lower string and 2 higher string that are offset half tone.
So I usually end-up with less movement in the standard tuning as I usually just stay on either those 4 lower or 2 higher strings depending on which note I've started.
Jumping between those two sections is not that much of a problem but I have to do it consciously.
But it still a lot better then just learning each scale and key separately! I just see no need for standard tuning in my playing and probably could get better at this "section jump" if I had used it more.
Currently gnome-shell is taking 135MB of ram, with other gdm/gnome related background services ranging in 700KB-3.2MB each to like 20MB together.
And it's as snappy as my sway config I log into depending on the needs.
I just spammed virtual desktop changes, opening Files, browsing, and it's as snappy as it is in sway.
I think gnome is getting a lot of unfair performance criticism online as it looks like something that would be slow. Maybe it was slow back in the starting gnome3 days. Maybe there are some heavy differences in how distros package it? (arch btw)
... though I will say that from my experience it's the KDE that's the slow one. I don't have it installed currently on this machine but had in the past and have it on my steam deck(which is stronger then this laptop). It feels sluggish and I have this bouncing cursor wait animation in my head right now just thinking about it.