Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Avalonia not rely on runtime marshaling #16273

Open
3 of 7 tasks
maxkatz6 opened this issue Jul 10, 2024 · 2 comments
Open
3 of 7 tasks

Make Avalonia not rely on runtime marshaling #16273

maxkatz6 opened this issue Jul 10, 2024 · 2 comments

Comments

@maxkatz6
Copy link
Member

maxkatz6 commented Jul 10, 2024

Is your feature request related to a problem? Please describe.

There is a relatively new trend in .NET libraries to avoid any interop code that results in runtime marshalling. Doing so theoretically benefits by removing unnecessary runtime dependencies, potentially improving trimming, and enhancing performance. Although it might not result in significant numerical improvements, we can still investigate and pick low-hanging fruits.

Packages that needs to be updated:

[DisableRuntimeMarshalling] is injected by default to all trimmable projects starting with this PR. But it's explicitly removed on these projects below which still rely on runtime marshalling.

  • Avalonia.OpenGL - the most important, as it's used on mobile, where we want to get rid of runtime marshalling. For the most part, we only need to update our GL functions source generator to avoid any runtime marshalling (and instead source generate it)
  • Avalonia.Vulkan - reuses the same source generator as Avalonia.OpenGL, the same problem.
  • Avalonia.Android - uses the same source generator as above, aside from that is compatible.
  • Avalonia.Win32 - full of dllimport calls, complicated.
  • Avalonia.X11
  • Avalonia.FreeDesktop - single DllImport, but need somebody who can devtest these changes.
  • Avalonia.LinuxFramebuffer - SetLastError usage

Describe the solution you'd like

Fixing these errors is not as trivial and depends on each project.
I had a quick look on how solution would look like for different projects:

  1. LibraryImprort - is the easiest for projects that only target .NET 7+ (mobile backends). Can still be applied on other projects like Avalonia.Base, where we have very little pinvokes.
  2. Update source generator - it's mostly related to OpenGL and Vulkan source gen. Right now it generates less optimal code with runtime marshalling. Which we can improve without changing any APIs, just by updating source generator. Haven't checked MicroCom, but it might be in the same situation.
  3. Manually ensure that all DllImports don't have runtime marshalling - routine and difficult one, potentially with high impact. Affects mostly X11 and Win32 backends.
  4. Use CsWin32 for Win32 backend. Makes it easier to maintain, and also lower impact. But also, won't be a small task.

COM Interop used for Win32 accessibility backend is also a blocker, but we are half-way to rewrite it anyway.

Additional context

Disabled runtime marshalling - important to mention, that this attribute changes default rules for marshalling. Which needs to be addressed especially for Win32 backend.

@maxkatz6
Copy link
Member Author

Related #8006

@maxkatz6
Copy link
Member Author

Additional issues to track:
Xamarin-iOS support for DisableRuntimeMarshalling xamarin/xamarin-macios#15684, seems like they are actively working on this.
Couldn't found equivalent Android tracking issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant