apitrace VS Avalonia

You have several tools, this can be done by printing debug messages using extensions such as KHR_debug, or using specific tools which will inject themselves between your OpenGL calls and your driver such as apitrace or RenderDoc. I recommend running your program in RenderDoc regularly even if everything seems to work fine as it may help you catch some subtle bugs.

That said, the profiling situation for non-NV users is not completely hopeless. You can still use API timer queries to get an idea of how long events take on the device. Tracy also supports GPU profiling, but I suspect it's just a fancy way of inserting timer queries. apitrace also claims to support profiling OpenGL apps, but I'd be wary of overhead as it's doing a lot of other things besides profiling.

At first I thought Feral probably used it accidentally, but this thread about the symbol's use in apitrace seems to shed some light:

I don't see anything wrong with your code, altough I'm not familiar with Avalonia or Silk. I suggest you try to use apitrace for (a probably long and painful day) debugging it.

I get that it's hard to debug without direct access, but isn't there some dump or log that they could generate and provide? Maybe something like using apitrace?

Pierre-Eric Pelloux-Prayer @pepp · 6 months ago Developer https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown is the basic doc. For Steam games I usually go to the game's folder (probably $HOME/.steam/steam/steamapps/common/Indivisible) and try to run the game with apitrace (apitrace trace indivisible-executable). It should print a line to indicate where the trace file is written to (apitrace: tracing to somefile.trace.

You might also want to look at AvaloniaUI[0] for a cross platform .NET GUI library. It is similar to WPF but much nicer to work with.

[0] https://github.com/AvaloniaUI/Avalonia

Production user here. There's no money gotchas. They're above reproach. In fact, I've received considerable free support from their devs on GitHub Issues [1].

The Avalonia business model is based on selling XPF, which runs WPF (Windows-only) apps on other platforms. That's very interesting to big corps with existing codebases.

See my comment [2]

[1] https://github.com/AvaloniaUI/Avalonia/issues

[2] https://news.ycombinator.com/item?id=39246988#39249128

Yes, but the portable GUI frameworks by Microsoft themselves are generally not very good, and they tend to be abandoned after a couple of years.

Avalonia is developed outside of the Microsoft corporate madness and seems to be slowly becoming the defacto cross-platform framework because it is expected to last a bit longer than a manager's attention span: https://avaloniaui.net/

Not my comment, but relevant here "The problem with compiling Skia to WASM is you'll lose any benefits of hardware graphics acceleration on the device."

(From https://github.com/AvaloniaUI/Avalonia/discussions/6831#disc... )

It's a bit of a hit and miss as of today. CLI, back-end and natively compiled libraries (think dll/so/dylib or even .lib/.a - you can statically link NAOT binaries into other "unmanaged" code) work best, GUI - requires more work.

Avalonia[0] and MAUI[1] have known working templates with it, but YMMV.

[0] https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/ / honorable mention https://github.com/VincentH-Net/CSharpForMarkup

[1] https://github.com/dotnet/maui (try out with just true in csproj - it is known to work e.g. on iOS)

For desktop, Avalonia, hands down.

https://avaloniaui.net/

Open source, powered by Skia, backed by JetBrains, and quite battle-tested at this point for small to medium-sized apps. In theory perfectly capable for enterprise as well, since it's basically a spiritual successor to WPF, which has been an industry standard for about 15 years.

They're diving into mobile and WASM well, but that's more of a recent effort and I haven't tested that yet.