Develop Reference

Unity 2D Canvas Scaler

I'm working in Unity, and something stuck in my mind. What is the difference between the UI Scale Mode options in the section of the canvas scaler component, can anyone explain it?
There are 3 UI Scale Mode options. Which of these 3 options should I use and what do they do?
Thanks in advance

You can check here for a more detailed explanation of each field: https://docs.unity3d.com/Packages/com.unity.ugui#1.0/manual/script-CanvasScaler.html
But basically:
Constant Pixel Size: means the UI elements will have the same pixel size always, no matter what size of screen do you have. So if you have a 100px X 100px button on your screen at 1920x1080 it will fill just a small portion of your screen, but if your screen resolution changes to 200x200 for example, than the button will be giant and fill a much bigger part of the screen now.
Scale With Screen Size: means exactly what it says, the UI will scale according to the screen size, so if you work and create your UI on a 960x540 screen and then change to 1920x1080 for example, your UI will scale, and in this case make the UI 2 times bigger because the screen is now 2 times bigger, so the aspect of the button will appear the same in all resolutions.
Constant Physical Size: uses DPI instead of pixels. DPI means "dots (pixels) per inch", meaning you it doesn't matter what the size of your screen is, the amount of pixels you define the UI will cover will remain the same, so for example if you have a 1920x1080 screen, and a 200x100 button, the button will be small on the screen, but if you play the game in a cellphone with lower resolution, 1280x720 for example, the button will remain with the same pixel density, 200x100, but since the screen has less pixels now the button will appear bigger, but in reality the resolution of the button in both cases remains the same.
But all of them also change the way anchors will work on your UI. The best way to know what you should use and what each one does is by testing yourself.
You can read more here as well for more information: https://docs.unity3d.com/Packages/com.unity.ugui#1.0/manual/HOWTO-UIMultiResolution.html

Make WPF window appear same size (in pixels) at every DPI

How can I make a WPF window (And its controls) have the same size, in pixels, regardless of the system DPI/scale?
My application determines its width and height based on the screen size, and will scale the content area automatically. I'd the controls to appear to all be at the standard "Smaller (100%)" scale.
Currently my application will scale up when on "Medium" or "Larger". I understand this is how WPF is designed to work, but I want to force it to not scale at higher scales. Changing the "DPI Aware" property in the application will have no affect on the size of it, just whether or not it is scaled properly vs being blurry due to being stretched.
If I have a small laptop screen with the default (100%) scale, and a desktop with a 1080p display at 125%, I want the controls to be the same size, pixel wise. This will make the application smaller on the 1080p screen, but my application will increase it's size to make it appear bigger. (The controls will be the same size in pixels, but the main area of my application, a canvas that can be drawn on, will be larger)

Aero borders cut off space from my WPF window

Unfortunately I can't provide screenshots for comparison now, since I'm unable to use Aero here at work, but I'm having the following problem:
I'm creating a small WPF application. My main window is not resizable, and the sizes and positions of everything inside are fixed. Everything works fine here using some pre-defined theme (it's "Windows Classic" most likely). Once I run the exe at home though - with Aero enabled - the border size is way bigger, but the actual total window size stays the same it seems to me. So the borders go "into" my window, shrinking the actual usable space and thus some of my controls are overlapped by the borders and it looks asymmetrical.
What can I do about this, if anything? Is there some option to make the borders be attached "outside" my used window space?
Edit: Here is an uploaded image of the Aero version. I hope the problem can be seen. (It's at the bottom)

In my opinion a static size is a bad way in wpf.
There are different solutions:
1. make your window a bit heigher or
2. reduce the margin between your used content elements or
2. use a dynamic size of your content. A grid with rowdefinitions set to "X*" where x is the height in propotion to total height of your content.
But im not sure ... you use a style in your app or is the style directly set into element? If you use a xaml stysle file, is it possible the style overrides your set position or margin properties?

How can I size a Form or a FlowLayoutPanel for printing larger than the Screen size?

I have a Form whose main panel is a FlowLayoutPanel that is exactly what I want to print (it is designed to look like a nicely formatted document... no buttons, etc. ... you right-click for commands).
So, I take advantage of DrawToBitmap to implement printing for almost free... I simply resize the Form such that the main panel is the size of the sheet of paper the user wants to print on (minus margins), which causes it to automatically flow its contents properly for that size. I then just use DrawToBitmap to render that FlowLayoutPanel and all its contents to the printed page. I can even scale to fit by growing the window larger than the page size (same aspect ratio), and then scaling down the Bitmap I get from DrawToBitmap. Works great...
BUT it only works if your screen is larger than the page size! Because any attempt to resize a Form or Control larger than the size of the screen + 12 pixels in either direction gets thwarted.
Ugh!! Why tease me with the simplicity and utility of DrawToBitmap if you're going to kill its applicability by refusing to resize larger than the screen? (rhetorical)
My questions:
Is there a way to circumvent that limit and get the Form or the FlowLayoutPanel to resize larger than the screen?
If not, is there a way to get to the FlowLayoutPanel's scrolled surface (not just the portion scrolled into view) such that I can size it to match the printed page and such that I can call DrawToBitmap on it?
If not, is there some other way to leverage my existing layout functionality to print? Or am I stuck essentially rewriting all that WinForms code just to generate the same Bitmap it'll already generate if my screen is bigger than my printed page??

I'm not sure, but would it be possible to do this all virtually. IE:
Dim FLP as FlowLayoutPanel = Form1.FlowLayoutPanel1
For Each flp_subobject as Object in FlowLayoutPanel.Children
FLP.Children.Add(flp_subobject)
Next
FLP.Height = MASSIVEHEIGHT
FLP.Width = MASSIVEWIDTH
DrawToBitmapFunction(FLP)
That is how I would do it, not that I have much experience with regards to exceeding screen limits etc. Let me know how this goes, as it pretty much just came straight out of my head on the spot :D

Silverlight 2 and large canvases?

I am working on an application that uses several large canvas controls (several thousand pixels across), layered on top of each other. The canvas controls themselves are completely invisible, but each contains a number of controls, mainly images.
My question is, is there a recommended maximum size for a canvas, or is it purely a memory issue? And also, are we better off setting the Canvas size to (0, 0) and making use of the fact that we can happily render controls outside of the bounds of the canvas?
Thanks,
G

Watch out: the maximum size of a Silverlight canvas is 32767 points. This is because the size of UIElements is not stored as floats as it is in WPF, but in 32 bit quantities of which 16 bits form the integer of size and 16 bits form the floating part of it. So make sure your canvas is not bigger than that and not going to be.
The solution which you would need to make it larger is to do the scrolling yourself and position the objects yourself. In effect you're recreating the canvas. This is called Virtualizing in WPF terms.
The memory consumption won't be bigger depending on the canvas size but depend only on the number of controls and the cumulative memory size of those controls. However, if you're going to have a lot of WPF objects, the layout phase does take considerable time with more (say, more than 1000) objects. If that's going to be a problem you need to code it yourself again and have a cache of unused WPF objects of the same type lying around (since WPF object creation is also quite slow).

From my understanding of the innards of Canvas, it should need no additional memory for being bigger.
The first thing that comes to my mind on having a non-zero sized Canvas is that it allows one to put items on it relatively to any of the four corners, which helps when e.g. resizing the container.