WPF control issues #656

Closed
devdept opened this Issue Oct 7, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@devdept

devdept commented Oct 7, 2015

Hi Alexandre,

Regarding the issue below (we care a lot about), we are in contact with Microsoft Redmond (WA) to solve it. I would need you to contact us to arrange an appointment with a the Microsoft's developers so you can explain them what's wrong with the D3DImage control and discuss with them how to improve it. Please drop us a line at info [at] devdept [dot] com ASAP.

Thanks so much in advance.

#519

@weltkante

This comment has been minimized.

Show comment
Hide comment
@weltkante

weltkante Oct 30, 2015

Contributor

Microsoft has been releasing source code for WPF DX interop (officially for the next 4.6.1 version but since it has public source code it might work on earlier versions?), maybe you want to check this out instead of using the SharpDX hosting. They use the same underlying technology (WPF D3DImage control) but may differ in the implementation details, so it may be useful to compare both implementations.

Note that you can still use SharpDX, just use the Microsoft control for hosting.

If you are experiencing the same issues with the Microsoft control hosting you might have better luck getting the problem fixed by posting an issue against their library.

Contributor

weltkante commented Oct 30, 2015

Microsoft has been releasing source code for WPF DX interop (officially for the next 4.6.1 version but since it has public source code it might work on earlier versions?), maybe you want to check this out instead of using the SharpDX hosting. They use the same underlying technology (WPF D3DImage control) but may differ in the implementation details, so it may be useful to compare both implementations.

Note that you can still use SharpDX, just use the Microsoft control for hosting.

If you are experiencing the same issues with the Microsoft control hosting you might have better luck getting the problem fixed by posting an issue against their library.

@QuantumDeveloper

This comment has been minimized.

Show comment
Hide comment
@QuantumDeveloper

QuantumDeveloper Oct 30, 2015

@weltkante as I can see they use delegate to render and it fires only 60 frames per second.
When control resize, it changes IntPtr for surface to render, which will lead to swapchain recreation. So, I dont think they really changed something here - they just write the same DX9 xontrol for DX11. Also I dont think they really understand what is efficient DX rendering, because example they upload present highly inefficient way of rendering. So, I am afraid, but seems nothing will change in better way, unfortunately.

@weltkante as I can see they use delegate to render and it fires only 60 frames per second.
When control resize, it changes IntPtr for surface to render, which will lead to swapchain recreation. So, I dont think they really changed something here - they just write the same DX9 xontrol for DX11. Also I dont think they really understand what is efficient DX rendering, because example they upload present highly inefficient way of rendering. So, I am afraid, but seems nothing will change in better way, unfortunately.

@weltkante

This comment has been minimized.

Show comment
Hide comment
@weltkante

weltkante Oct 30, 2015

Contributor

Seriously, you need to work on your attitude. I just hinted you to an alternate way to resolve your problems directly with Microsoft instead of waiting for a developer who already stated (in the other issue) he is not interested and has no time.

Most of your arguments are wrong or don't matter. If you are currently using SharpDX hosting to do WPF interop you are already using a D3DImage, right? Switching over to Microsofts implementation allows you to file bugs against them and resolve your issues with them, but here you complain about totally unrelated stuff like performance or their implementation details (some of which you clearly don't understand).

Anyways I give you even another suggestion: if performance is so important to you, you should switch over to UWP, you got a much better Direct3D interop story there and have full control over your swap chains and everything, while still being able to mix in XAML UI.

If you need WPF to stay compatible to older OS versions you should stop complaining and start figuring out whats wrong, and then get it fixed with Microsoft. Don't wait for someone else to do your work.

Contributor

weltkante commented Oct 30, 2015

Seriously, you need to work on your attitude. I just hinted you to an alternate way to resolve your problems directly with Microsoft instead of waiting for a developer who already stated (in the other issue) he is not interested and has no time.

Most of your arguments are wrong or don't matter. If you are currently using SharpDX hosting to do WPF interop you are already using a D3DImage, right? Switching over to Microsofts implementation allows you to file bugs against them and resolve your issues with them, but here you complain about totally unrelated stuff like performance or their implementation details (some of which you clearly don't understand).

Anyways I give you even another suggestion: if performance is so important to you, you should switch over to UWP, you got a much better Direct3D interop story there and have full control over your swap chains and everything, while still being able to mix in XAML UI.

If you need WPF to stay compatible to older OS versions you should stop complaining and start figuring out whats wrong, and then get it fixed with Microsoft. Don't wait for someone else to do your work.

@QuantumDeveloper

This comment has been minimized.

Show comment
Hide comment
@QuantumDeveloper

QuantumDeveloper Oct 30, 2015

First of all:

  1. I am not complaining. I just pointing disadvatages of their solution and I have already created a several issues on MS branch at github.
  2. I am not using D3DImage to render DX content in WPF.

First of all:

  1. I am not complaining. I just pointing disadvatages of their solution and I have already created a several issues on MS branch at github.
  2. I am not using D3DImage to render DX content in WPF.
@weltkante

This comment has been minimized.

Show comment
Hide comment
@weltkante

weltkante Oct 30, 2015

Contributor
  1. I have already created a several issues on MS branch at github.

I saw the other issues, some are correct, some look questionable, on the latter I added some comments.

  1. I am not using D3DImage to render DX content in WPF.

Ok I misunderstood this then, sorry. However I don't think you'll get an alternative for D3DImage interop with WPF anytime soon, it doesn't look like MS is investing much resources there.

If you don't really need WPF you should consider UWP, they've done a lot of things much better.

Contributor

weltkante commented Oct 30, 2015

  1. I have already created a several issues on MS branch at github.

I saw the other issues, some are correct, some look questionable, on the latter I added some comments.

  1. I am not using D3DImage to render DX content in WPF.

Ok I misunderstood this then, sorry. However I don't think you'll get an alternative for D3DImage interop with WPF anytime soon, it doesn't look like MS is investing much resources there.

If you don't really need WPF you should consider UWP, they've done a lot of things much better.

@QuantumDeveloper

This comment has been minimized.

Show comment
Hide comment
@QuantumDeveloper

QuantumDeveloper Oct 30, 2015

I know about UWP and like their solution, but I dont like UWP limitations. On WPF I have more freedom in that what I can do with my PC resources. I dont like an idea of being locked inside virtual sandbox of application on desktop with no access to other parts of PC if I need them.

I know about UWP and like their solution, but I dont like UWP limitations. On WPF I have more freedom in that what I can do with my PC resources. I dont like an idea of being locked inside virtual sandbox of application on desktop with no access to other parts of PC if I need them.

@weltkante

This comment has been minimized.

Show comment
Hide comment
@weltkante

weltkante Oct 30, 2015

Contributor

UWP desktop applications are not locked as far as I know, only for store applications you need to limit yourself to the allowed API. I'm still experimenting with it myself though, so I may have misunderstood something.

Contributor

weltkante commented Oct 30, 2015

UWP desktop applications are not locked as far as I know, only for store applications you need to limit yourself to the allowed API. I'm still experimenting with it myself though, so I may have misunderstood something.

@QuantumDeveloper

This comment has been minimized.

Show comment
Hide comment
@QuantumDeveloper

QuantumDeveloper Oct 30, 2015

Ok, but I need VS like tabbed docking control, which UWP hasnt. It present only on WPF dektop for now if I didnt miss anything. Also what about licensing and distributing my app to other people without store? Could I do that on UWP?

Ok, but I need VS like tabbed docking control, which UWP hasnt. It present only on WPF dektop for now if I didnt miss anything. Also what about licensing and distributing my app to other people without store? Could I do that on UWP?

@weltkante

This comment has been minimized.

Show comment
Hide comment
@weltkante

weltkante Oct 30, 2015

Contributor

Those controls can certainly be implemented but it may indeed take a while until some become available. About distribution I'm not sure how you distribute UWP applications outside the store, but I heared that it is possible to allow business selling applications without having to go through the store.

A quick google search showed up sideloading:

If you have an app that you don’t want to sell in the Store, like a line-of-business (LOB) app, you can sideload that app so that other users in your company can use it.

I don't know if having customers to "unlock" sideloading in the control panel would be prohibitive for you, so you might have to look into it more before its clear whether it is a possible option. It may also be possible to have this done by an installer, no idea, the registry keys and necessary steps are documented at least.

Personally I don't see much problems with restricting myself to allowed APIs though, considering they even opened up JIT code generation in store apps, they are becoming more permissive now.

Anyways I guess this starts to go off topic ;-) UWP is just an option and may not be ideal for everyone (for example if you still want to support older OS versions its no option anyways). Just wanted to make sure you (and possibly other people coming across this issue) are aware of the alternatives.

For D3D interop (and mixing with XAML UI) it currently it is certainly superior to WPF and I don't think this will change anytime soon, considering the slow (if any) progress made on the WPF side.

Contributor

weltkante commented Oct 30, 2015

Those controls can certainly be implemented but it may indeed take a while until some become available. About distribution I'm not sure how you distribute UWP applications outside the store, but I heared that it is possible to allow business selling applications without having to go through the store.

A quick google search showed up sideloading:

If you have an app that you don’t want to sell in the Store, like a line-of-business (LOB) app, you can sideload that app so that other users in your company can use it.

I don't know if having customers to "unlock" sideloading in the control panel would be prohibitive for you, so you might have to look into it more before its clear whether it is a possible option. It may also be possible to have this done by an installer, no idea, the registry keys and necessary steps are documented at least.

Personally I don't see much problems with restricting myself to allowed APIs though, considering they even opened up JIT code generation in store apps, they are becoming more permissive now.

Anyways I guess this starts to go off topic ;-) UWP is just an option and may not be ideal for everyone (for example if you still want to support older OS versions its no option anyways). Just wanted to make sure you (and possibly other people coming across this issue) are aware of the alternatives.

For D3D interop (and mixing with XAML UI) it currently it is certainly superior to WPF and I don't think this will change anytime soon, considering the slow (if any) progress made on the WPF side.

@xoofx xoofx closed this Dec 24, 2015

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