-
Notifications
You must be signed in to change notification settings - Fork 1.2k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Open Sourcing Update #2554
Comments
Question for you. I understand PresentationNative has a dummy project file that extracts the prebuilt DLL from a NuGet package. AFAICT, there is no such mechanism for bilinearspan.lib. |
There are build targets in place that transparently supply missing ProjectRefereces from prebuilt-libs or DLL’s. Wpfgfx Is designed to be buildable by anyone, and you should be able to do so right away. |
Is there any plan to open source (buildable of course!) components like |
@richlander Can you help answer @yekanchi ? |
@wjk Take a look at:
and then:
That should give you the basic idea of how the |
Congratulations on this milestone. Your team has been working on this for months including holidays and we appreciate the teams efforts.
Can you give us some insight into the bug fixes and release plans going forward.
Thanks again,
Craig
From: Vatsan Madhavan [mailto:[email protected]]
Sent: Tuesday, February 11, 2020 6:18 PM
To: dotnet/wpf
Cc: Subscribed
Subject: [dotnet/wpf] Open Sourcing Update (#2554)
We are happy to announce that we are open sourcing (#2553<#2553>) of native components in WPF – wpfgfx_cor3.dll and penimc_cor3.dll. With this, we have completed all planned open-sourcing work for WPF on .NET Core.
PresentationNative_cor3.dll and a small library used by wpfgfx_cor3.dll (bilinearspan.lib) contain proprietary content and are not being open sourced.
These sources have gone through extensive preparatory work – for e.g., sanitizing them to remove content that is not suitable for open-sourcing (e.g., internal-bug database references, user names etc.) of which there were several thousands of instances, identifying and excluding proprietary IP, and security cleanup (for which we used Semmle – please check it out at https://www.semmle.com).
In addition to this news, we have been making continuous improvements to .NET Core 3.1. You can see information about .NET Core January 2020 update here (dotnet/core#4119<dotnet/core#4119>), and the February 2020 update will be out soon this month.
Cheers!
WPF Team
@dotnet/wpf-developers<https://github.com/orgs/dotnet/teams/wpf-developers>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#2554?email_source=notifications&email_token=AFJQKYGVQBXXBMODKDSCGZDRCNE3DA5CNFSM4KTPZ3S2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IMY53RQ>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFJQKYFKV35NNQPN4JRFCD3RCNE3DANCNFSM4KTPZ3SQ>.
|
Excellent, I love seeing any and all effort put in towards WPF improvements, including open sourcing it. Thank you for your efforts. |
Congratulations! If I remember it correctly the initial goals of this repo were:
Is this project now in a state were feature suggestions from the community will be tackled for the .NET Core / WPF 5.0 release? I would like to see an update for the WPF Roadmap and see what the WPF team is planning for V5.0 and if the community can collaborate with the team for V5.0 (new features, fixes, suggestions...). The readme.md's status section would also need an update. |
Is there a way those remaining proprietary libraries can be blobed as included Restricted Freeware binaries to assist porting efforts? Also is there any way the API documentation of the said binaries could be released so an alternative implementation can be written@ Finally is there a way that the Windows version of .Net, and it's remaining proprietary components have it's license adjusted to permit running under non-Microsoft platforms,.so it can be used in Binary form as Freeware for porting stacks. |
@Ruedii what exactly do you mean? They are already distributed as binary blobs through a nuget archive downloaded during the build. However those DLL and lib are native code not .NET, it doesn't run on non-windows platforms in the first place - you'll have to replace them with a ported implementation just like you have to replace DirectX or HWND usage with ported implementations. Note that .NET Core on Linux/Mac doesn't even have the concept of C++ mixed mode assemblies so porting those parts requires rewriting them anyways. For what its worth bilinearspan.lib has a corresponding source file so I don't know exactly why its distributed as a blob (maybe its a specially optimized version they distribute) - so this leaves only PresentationNative which isn't open sourced, and you'll just have to treat it like porting DirectX and HWND usage. Yes, having the API to PresentationNative.dll documented would be "nice to have", but honestly its just text layout and you most likely won't want to reimplement the API anyways. I already looked at it and the API is highly coupled to the implementation, what you'll want to do is replace the text layout logic in C# to use a different library instead of reimplementing the PresentationNative API for the text layout engine. |
For what it's worth I believe the text layout is long overdue a major update anyway to bring it on par with latest DirectWrite (languages support, vertical text, color fonts, math etc.), so perhaps there is an opportunity there for having this bit replaced with open source. I agree with @weltkante though that that would be of little help with running it on other platforms. |
We will research this and get back to you 😄. I honestly don't know the answer, but I suspect that we'll figure this out as part of dotnet/core#2955.
A lot of this can be done in DirectWriteForwarder + PresentationCore. What's in PresentationNative has to do with logical layout of lines, grids etc. I'm not saying that the latter is uninteresting or unimportant - just that there are a great many things related to text rendering can be improved now and PresentationNative (i.e. lack of its sources) would probably not hinder these improvements.
Apologies for being being the bearer of a "no" answer again about this 😞, but I'm afraid that PresentationNative related documentation is not something we expect to put out. |
Also in |
@richlander any update on this? |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
We are happy to announce that we are open sourcing (#2553) native components in WPF –
wpfgfx_cor3.dll
andpenimc_cor3.dll
. With this, we have completed all planned open-sourcing work for WPF on .NET Core.PresentationNative_cor3.dll
and a small library used bywpfgfx_cor3.dll
(bilinearspan.lib
) contain proprietary content and are not being open sourced.These sources have gone through extensive preparatory work – for e.g., sanitizing them to remove content that is not suitable for open-sourcing (e.g., internal-bug database references, user names etc.) of which there were several thousands of instances, identifying and excluding proprietary IP, and security cleanup (for which we used Semmle – please check it out at https://www.semmle.com).
In addition to this news, we have been making continuous improvements to .NET Core 3.1. You can see information about .NET Core January 2020 update here (dotnet/core#4119), and the February 2020 update will be out soon this month.
Cheers!
WPF Team
@dotnet/wpf-developers
The text was updated successfully, but these errors were encountered: