Please remove changes to SharpDX.sln.DotSettings. The other changes seem to affect only the sample, so they look fine for me.

@ArtiomCiumac I would like to integrate this change into Toolkit as well. Could you point me to a place where this should go? I started in SwapChainGraphicsPresenter but I don't get the actual reference to SwapChainPanel there (only the COM interface) so can't get CompositionScale properies and even.

You were looking into right place - take a look at this line and try to obtain in the same way a reference to SwapChainPanel. Description.DeviceWindowHandle may not be the best name, as it contains a handle for Desktop platform, but on WinRT it contains a reference to the host control - either an CoreWindow, SwapChainBackgroundPanel or a SwapChainPanel. Make sure you will not break the functionality for other platforms.

For me they are not ready to integrate. They are 'only' the Sample but mess around with the structure. Please don't integrate it as is. It is a workaround for doing some DPI-scaling, but implements a lot of class variables etc. where they don't really belong just to have some handy access to them. I would rather like to keep a clean sample missing the functionality as starting point than having one sample were it is fixed some way. Because of the current stucture I also doubt one can integrate it in the Toolkit, things have to compile for Win81 to have SwapChainPanel.

for example I have seen no use of

private float lastCompositionScaleX = 0;
private float lastCompositionScaleY = 0;

anywhere. So why adding it? Also I doubt just changing getter of Width (and Height) from

return (int)(width * DeviceManager.Dpi / 96.0);

to

return (int)(width * panel.CompositionScaleX);

makes the application completely DPI-Aware. I think this might just work in you special case, but will it work everywhere? I don't see

DisplayInformation.LogicalDpi

being used anywhere with this width-calculation exchanged.

Looking up the MS-Samples DirectXHelper gives this handy method:

    // Converts a length in device-independent pixels (DIPs) to a length in physical pixels.
inline float ConvertDipsToPixels(float dips)
{
    static const float dipsPerInch = 96.0f;
    return floorf(dips * Windows::Graphics::Display::DisplayInformation::GetForCurrentView()->LogicalDpi / dipsPerInch + 0.5f); // Round to nearest integer.
}

This is a reference implementation and handles all scaling and has a solution to your rounding method. You should dig further into this. [sic!] Dips instead of Dpis and not in use...

Ok, sorry. I missed your use of

private float lastCompositionScaleX = 0;
private float lastCompositionScaleY = 0;

in CompositionScaleChanged event. This is ok, to avoid unnecessary reinitialization. But since changes might not affect integer rounded SwapChain size, I would even remember an integer of last integer rounded SwapChain size instead :) Also found by dinging into Helper classes, a simple

return (int)(width * panel.CompositionScaleX + 0.5);
return (int)(height * panel.CompositionScaleY + 0.5);

will fix rounding offset.

Thanks for looking into this. You are right - I didn't use LogicalDPI directly after all. But this is because CompositionScale properties include this value already. Here is how I understand this works:

Let's say we have SwapChainPanel with Size=320x200 (like in the sample).

1. If you run it on a screen that has 100% logical scaling than LogicalDpi is 96 and CompositionScale will return 1.0.
2. If you run it at 140% we gat 96*140%=134.4 hence LogicalDpi is 134.4 and CompositionScale is 1.4.

This handles the Logical DPI settings of the screen but SwapChainPanel does more. It also calculates all transformations applied to the panel or any of it's ancestors in visual tree.
http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.controls.swapchainpanel.compositionscalex

So if we apply RenderTransform with scale 3 we will get:

1. On screen at 100% logical DPI the CompositionScale is 3.0. If we apply this to calculate back buffer size we will get 960x600 that coresponds to size of this element rendered on screen (so it cancels the scaling up artifacts).
2. On screen at 140% logical DPI the CompositionScale is 1.4*3=4.2 that gives size of 1344x840.

So we just need to use the CompositionScale properties in two places:

1. To calculate size of the back buffer.
2. To apply inverse transformation on the SwapChain2.MatrixTransform

This is what I am about to believe now, too. Thought it was more complicated, because of all that "logicalDpi here, deprecated-behaviour there" mess. Once merged I will apply the changes I suggested If you don't. But after digging into the MS-Sample I am convinced these parameters are all needed. Thank you, this was still on my agenda for Win81-Sample. I think adding some multithreaded rendering example would be nice, too :)

Great. Please go ahead and make the adjustment as you see fit. And I'm looking forwar to your multithreaded sample too :)

I would prefer not to introduce other specific samples like multithreading (as there is already one in the samples in SharpDX). You can always open and share your own repository of additional samples if you want.

Thought it would be nice, since it makes most sense to me just with SwapChainPanel to have multi-threaded rendering. It allows independent SwapChain and multiple instances to be synchronized with Xaml-Rendering.

Sure, lots of things can make sense, but I don't want to introduce too many variations. Samples in SharpDX are mainly bootstrapping samples and gives roughly an idea of the API (Sure you can find some exceptions, but this is still a general goal).

I encourage you to open your own repository and commit all your samples/variations there where you will be able to have much more freedom, explain them in a readme... etc. Some people are doing this and it works well. Check for example this repository https://github.com/RobyDX/SharpDX_Demo

I see. Problem is no one will find them, and even fewer people contribute. It makes little sense for me to maintain such an own opensource project with samples. But good to know you don't want any more samples, so I for my part will most likely just do it for me when needed.

@TheWhiteAmbit So just because I'm saying that the main SharpDX repository should not contain all samples using it, you are choosing to not release any of your samples and keep them for yourself?

Samples in SharpDX for the core APIs (Direct3D11, DirectWrite...etc.) are not meant to show all the possibilities of these APIs (look at D3D11 samples, it is just spinning cube) nor all the possibilities to integrate them in an OS/specific platform...etc. Please understand this, this is not against you. Continue to share your work with others, but SharpDX is really not a central place to host every possible use of it.

What is exactly the status of this pull-request, is it ok to merge it or not?

Yes, it is not that I have the samples already. Because it has little use to put work in having samples released no one uses, I will not even create them. Honestly, people will use the samples in the main repository, and contribute only there. So I will not put my time in creating samples to be just forgotten - have been at this point with open source. And in case I need f.e. multi-threading for myself, I would not do the extra work to release a stripped down sample no one finds in another repository. Open source makes no sense if you just release your code, and have no one working on it and barely find people using it. It is not worth the effort then. I must accept if you want no more basic samples in the repository. But for me it makes no sense releasing SharpDX samples somewhere else.

PS: I think it would be good to merge the pull-request, but I think it needs some polishing. This can be most easily applied after merge.