You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
Manually ensure that all DllImports don't have runtime marshalling - routine and difficult one, potentially with high impact. Affects mostly X11 and Win32 backends.
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.
The text was updated successfully, but these errors were encountered:
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.
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.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:
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.
The text was updated successfully, but these errors were encountered: