WPF 4.6 and beyond
At the recently held online conference dotNetConf organized by Microsoft, many interesting things were told. And since there was a large number of discussions about WPF, that it is very much alive , I would like to make a brief overview of the report of WPF program managers, what is waiting for us in the release, what you can already see and what is going on. Everything is really so bad and will there be an analogue of the new engine for WPF, such as Razor for ASP.NET.
On November 12, 2014, the WPF blog came to life (it is now active too), and the framework development plan was presented.
Hereinafter, screenshots from the video, so that the quality is not very, but you can see everything.
')
At the beginning of the performance , the hosts Uni Ravindranathan and Harikrishna Menon mentioned that there are things that are still in development, and they have no right to tell about them, NDA and all that. But what they can show is encouraging and it is clear that the work is underway. Looking ahead, I will say that first of all the developers thought about speed, for example, how to reduce the visual tree for a specific target platform.
Key development areas are shown in the screenshot below:
The developers claim that WPF is not going anywhere, and contrary to current rumors that WPF is being cut out from the operating system - this is not true. DotNet part of the OS, and WPF part of the OS and it will be given no less attention than other components. Microsoft is confident that applications for the OS will be written on WPF for a long time.
On the Connect portal, all the bugs that had more than 10 votes were revised and rediscovered. And now there is still an opportunity to influence what features / bugs will be developed.
In the next WPF release, issues related to issues will be resolved:
As it used to be tight with transparency. Workarounds apparently were, but difficult.
To use transparent child windows, you need Windows 8 and above, as well as .NET 4.5.2.
Well, one more detail, in app .manifest, you need to specify that this feature is supported by the OS. Those. in the application section write the following:
<application>
<! - Windows 8 ->
<supportedOS Id = "{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
</ application>
Another popular question is what to do with cursors when zooming in on the screen. The cursor is getting bigger too. It was necessary to manually determine that the scale increased and overload the cursors to the desired size. That everything was beautiful and neat. Now you can specify in the cursor constructor what to do if the display scale changes.
Another perfectionist hell was that for the drop-down list, the right border was cut off, and it looked like this from a scape. The new version is fixed.
In general, this problem is present for all components with an enlarged display scale. The reason is the incorrect display of the background for the components.
The problems described relate to the existing code, but everyone is more interested in what will happen next, what new things to expect from WPF.
The WPF team wants to reduce the delivery cycle of updates and shorten as much as possible. For updates to be released more than once every six months, when perhaps you don’t need any of this, but as your queries and bugs are realized.
In addition, a lot of attention is paid to backward compatibility. Since WPF is a system thing, support for DX12 or building a part of components based on DX12 can affect a number of already released programs. We can not throw them to the mercy of fate and must find some solution to ensure backward compatibility. This is of course a big problem. If you are concerned with performance issues, the changes should feel the maximum number of users.
An absolutely new thing that has not been mentioned anywhere else before the conference is AppLocal. Perhaps this is the biggest change now. It lies in the fact that WPF as a platform can be delivered using the correct version of NuGet package . Those. Each version of the application comes with its own unique version of WPF. The developers guarantee that you will get the best or the same speed as compared to the built-in version. More often, there will be an improvement in performance.
This version of WPF will be compatible with the built-in, but at the same time, you can build WPF versions on top of NetCore.
As a demonstration of the work of the new version of WPF, a demo with this design is given.
First, the application is loaded with builds 4.5.2. It is seen that the links go to the old version when developing and there will be an appeal to the GAC at runtime.
Now magic will happen. In the drop-down menu for assemblies, select the item “Add NuGet packages” and you can set the desired local WPF assembly. Unfortunately, this is currently available only to WPF developers, the screenshot below shows that the local repository is used.
During the installation, the links from the GAC assemblies to the local ones are replaced and in the Referencies list there appear quite a lot of new assemblies that your application needs for a specific platform.
Since this is not a ready solution, you need to do a bit of shamanism with configuration files and then everything will work.
After that, a comparison with version 4.5.2 can be made, by how much / element tree for the graphical interface of the application will be greatly reduced. So, for a fairly simple interface on the .net 4.5.2 version, 281 elements were created.
After applying the NuGet package with the local version of WPF, it turned out 230.
The developers promise deferred initialization of components, so that they will be initialized only when they fall into the active user zone. They promise that it will be possible to connect it in one motion, i.e. attribute.
Further review of the Blend and removal of performance metrics, which have already been separately consecrated in many places, I think.
In general, the presenters strongly urged the community to send them more interesting interesting cases of using WPF and in which places there are problems and gags. So write them a letter =)
In this context, it becomes even more interesting to know what will happen to WPF and Universal Application. Is it worth it to migrate, is it difficult, and in general when it is worth migrating and in which cases it is not. Of course, the basic skills for working with WPF remain in demand and relevant to the Universal App, but why then so much noise? These questions will be answered by Kostya Kichinsky , an expert on software development technologies, Microsoft, at the Desktop UI & Business Application conference on April 11th.
The report covers the main issues concerning the Universal App and WPF:
Come , it will be interesting!
On November 12, 2014, the WPF blog came to life (it is now active too), and the framework development plan was presented.
Hereinafter, screenshots from the video, so that the quality is not very, but you can see everything.
')
At the beginning of the performance , the hosts Uni Ravindranathan and Harikrishna Menon mentioned that there are things that are still in development, and they have no right to tell about them, NDA and all that. But what they can show is encouraging and it is clear that the work is underway. Looking ahead, I will say that first of all the developers thought about speed, for example, how to reduce the visual tree for a specific target platform.
Key development areas are shown in the screenshot below:
- Performance, speed when scrolling, data virtualization. Support for high pixel density screens. Many rightly criticize WPF for its speed, especially when scrolling.
- Support for DX11 and DX12
- Support for modern equipment. Responsiveness and reaction to touch events.
- Toolkit for development and debaga applications.
The developers claim that WPF is not going anywhere, and contrary to current rumors that WPF is being cut out from the operating system - this is not true. DotNet part of the OS, and WPF part of the OS and it will be given no less attention than other components. Microsoft is confident that applications for the OS will be written on WPF for a long time.
Immediate WPF Improvement Plans
On the Connect portal, all the bugs that had more than 10 votes were revised and rediscovered. And now there is still an opportunity to influence what features / bugs will be developed.
In the next WPF release, issues related to issues will be resolved:
- performance and touch devices
- scrolling and virtualization
- also made it possible to create transparent child windows.
As it used to be tight with transparency. Workarounds apparently were, but difficult.
To use transparent child windows, you need Windows 8 and above, as well as .NET 4.5.2.
Well, one more detail, in app .manifest, you need to specify that this feature is supported by the OS. Those. in the application section write the following:
<application>
<! - Windows 8 ->
<supportedOS Id = "{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
</ application>
Another popular question is what to do with cursors when zooming in on the screen. The cursor is getting bigger too. It was necessary to manually determine that the scale increased and overload the cursors to the desired size. That everything was beautiful and neat. Now you can specify in the cursor constructor what to do if the display scale changes.
Another perfectionist hell was that for the drop-down list, the right border was cut off, and it looked like this from a scape. The new version is fixed.
In general, this problem is present for all components with an enlarged display scale. The reason is the incorrect display of the background for the components.
The problems described relate to the existing code, but everyone is more interested in what will happen next, what new things to expect from WPF.
The WPF team wants to reduce the delivery cycle of updates and shorten as much as possible. For updates to be released more than once every six months, when perhaps you don’t need any of this, but as your queries and bugs are realized.
In addition, a lot of attention is paid to backward compatibility. Since WPF is a system thing, support for DX12 or building a part of components based on DX12 can affect a number of already released programs. We can not throw them to the mercy of fate and must find some solution to ensure backward compatibility. This is of course a big problem. If you are concerned with performance issues, the changes should feel the maximum number of users.
Applocal
An absolutely new thing that has not been mentioned anywhere else before the conference is AppLocal. Perhaps this is the biggest change now. It lies in the fact that WPF as a platform can be delivered using the correct version of NuGet package . Those. Each version of the application comes with its own unique version of WPF. The developers guarantee that you will get the best or the same speed as compared to the built-in version. More often, there will be an improvement in performance.
This version of WPF will be compatible with the built-in, but at the same time, you can build WPF versions on top of NetCore.
As a demonstration of the work of the new version of WPF, a demo with this design is given.
First, the application is loaded with builds 4.5.2. It is seen that the links go to the old version when developing and there will be an appeal to the GAC at runtime.
Now magic will happen. In the drop-down menu for assemblies, select the item “Add NuGet packages” and you can set the desired local WPF assembly. Unfortunately, this is currently available only to WPF developers, the screenshot below shows that the local repository is used.
During the installation, the links from the GAC assemblies to the local ones are replaced and in the Referencies list there appear quite a lot of new assemblies that your application needs for a specific platform.
Since this is not a ready solution, you need to do a bit of shamanism with configuration files and then everything will work.
After that, a comparison with version 4.5.2 can be made, by how much / element tree for the graphical interface of the application will be greatly reduced. So, for a fairly simple interface on the .net 4.5.2 version, 281 elements were created.
After applying the NuGet package with the local version of WPF, it turned out 230.
Performance improvement
The developers promise deferred initialization of components, so that they will be initialized only when they fall into the active user zone. They promise that it will be possible to connect it in one motion, i.e. attribute.
Further review of the Blend and removal of performance metrics, which have already been separately consecrated in many places, I think.
In general, the presenters strongly urged the community to send them more interesting interesting cases of using WPF and in which places there are problems and gags. So write them a letter =)
In this context, it becomes even more interesting to know what will happen to WPF and Universal Application. Is it worth it to migrate, is it difficult, and in general when it is worth migrating and in which cases it is not. Of course, the basic skills for working with WPF remain in demand and relevant to the Universal App, but why then so much noise? These questions will be answered by Kostya Kichinsky , an expert on software development technologies, Microsoft, at the Desktop UI & Business Application conference on April 11th.The report covers the main issues concerning the Universal App and WPF:
- The development of WPF and the emergence of WinRT
- Unification of the Windows platform and UAP
- WPF Investments
- How WPF fits in with the UAP + migration matrix (when and how to migrate, and when not)
Come , it will be interesting!
Source: https://habr.com/ru/post/255263/
All Articles