-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Screens API refactor #16295
Screens API refactor #16295
Conversation
…es of backend, use Microsoft.Windows.CsWin32 for interop
One breaking change that I would love to change, but can't - make Bounds and WorkArea nullable, and instead add non-nullable Size. Because we can get public class Screen
{
+ public PixelSize Size { get; }
- public PixelRect Bounds { get; }
+ public PixelRect? Bounds { get; }
- public PixelRect WorkArea { get; }
+ public PixelRect? WorkArea { get; }
} We might move this specific change to 12.0, cc @kekekeks |
namespace System.Runtime.InteropServices | ||
{ | ||
[global::System.AttributeUsage(global::System.AttributeTargets.Method, Inherited = false)] | ||
internal sealed class UnmanagedCallersOnlyAttribute : global::System.Attribute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: I used function pointers in netstandard2.0, and it even works on net framework.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you checked with x86 arch? It's the one with weird calling conventions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC one of the reasons for that attribute was to ensure that the function has a proper native->managed transition and is even callable with the corresponding calling convention.
.NET Framework isn't aware of the attribute and isn't likely to setup a proper native->managed transition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I believe that it's not safe to do.
@@ -43,14 +66,44 @@ virtual HRESULT GetScreen (int index, AvnScreen* ret) override | |||
|
|||
ret->Scaling = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does anybody remember why we set scaling to 1? Instead of using an actual value (more likely between 2 and 3 for most main displays). MacOS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our Screen API reports layout scaling, not DPI. macOS always uses logical coordinates for window positioning, so the reported value is 1.
We could extend the API to report both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our Screen API reports layout scaling
Is it used anywhere like that? It's also not intuitive.
Normally people would use Window.DesktopScaling for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other implementations like qtbase and chromium just return dpi scaling, not layout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will keep it as is for now
Added some screen integration tests as well. PR is ready. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
@@ -43,14 +66,44 @@ virtual HRESULT GetScreen (int index, AvnScreen* ret) override | |||
|
|||
ret->Scaling = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our Screen API reports layout scaling, not DPI. macOS always uses logical coordinates for window positioning, so the reported value is 1.
We could extend the API to report both.
namespace System.Runtime.InteropServices | ||
{ | ||
[global::System.AttributeUsage(global::System.AttributeTargets.Method, Inherited = false)] | ||
internal sealed class UnmanagedCallersOnlyAttribute : global::System.Attribute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you checked with x86 arch? It's the one with weird calling conventions.
namespace System.Runtime.InteropServices | ||
{ | ||
[global::System.AttributeUsage(global::System.AttributeTargets.Method, Inherited = false)] | ||
internal sealed class UnmanagedCallersOnlyAttribute : global::System.Attribute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I believe that it's not safe to do.
src/Avalonia.Controls/Primitives/PopupPositioning/ManagedPopupPositionerPopupImplHelper.cs
Show resolved
Hide resolved
You can test this PR using the following package version. |
@kekekeks removed incorrect UnmanagedCallersOnly usage, changed macOS impl to use com pointer, and moved GetHashCode/Equals impl to another class that inherits Screen. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
* Draft new API * Push reusable ScreensBaseImpl implementation * Fix tests and stubs * Update ScreensPage sample to work on mobile + show new APIs * Reimplement Windows ScreensImpl, reuse existing screens in other places of backend, use Microsoft.Windows.CsWin32 for interop * Make X11 project buildable, don't utilize new APIs yet * Reimplement macOS Screens API, differenciate screens by CGDirectDisplayID * Fix build * Adjust breaking changes file (none affect users) * Fix missing macOS Screen.DisplayName * Add more tests + fix screen removal * Add screens integration tests * Use hash set with comparer when removing screens * Make screenimpl safer on macOS as per review * Replace UnmanagedCallersOnly usage with source generated EnumDisplayMonitors * Remove unused dllimport * Only implement GetHashCode and Equals on PlatformScreen subclass, without changing base Screen # Conflicts: # api/Avalonia.nupkg.xml
What does the pull request do?
I skipped Linux because I have no idea how it works and can't properly test it locally.
Which also means, Linux still returns new Screen instance on each read, basically an old behavior.
See #15901 for details
Updated API:
Checklist
Breaking changes
ctor.Screens(IScreenImpl)
is now PrivateAPI. It should not break any app, as IScreenImpl by itself was a private API since 11.0.Fixed issues
#15382
#11512
#15637
#15901