I am using a horizontal long bar in my application.
The size of screen varies upon the devices, so maintaining a size in resources is not a good practice.
Is it possible to repeat the image in horizontal axis in wp7.
There is no repeat behavior in Silverlight's XAML (unlike WPF which supports it).
It is not recommanded to follow this way on the phone. You should create a larger image which includes the tiled effect at design time. You app will run faster because it will reduce the amount of work your app needs to do.
Currently Windows Phone 7 only supports 480 x 800 screen resolutions, although this will change in Windows Phone 8. Why not just resize the background? If you really want, you could create a repeating background image in an image editor, set it as the background image, and set stretch to none.
Related
I wanted to customize my start menu such that some of my tiles are large. But I have noticed that windows allows only small and medium sizes for certain tiles.
I wanted to make a tile large in size, so is there any way to tweak windows to allow me to choose my tile size of my own choice??
Please help?
If the application is not UWP and is a classic desktop application, only the small and medium options are available. Only the medium tile option is required for any app, and windows takes the app icon for that tile size. For the 'small' size it just scales the medium size image.
But when it comes to UWP apps, it is the developer's choice on which sizes to support for their apps according to the Microsoft Docs
To enable wide and large tile sizes, you need to provide the Wide310x150Logo and Square310x310Logo. Also, if possible, you should provide the Square71x71Logo for the small tile size (otherwise we will downsize your required Square150x150Logo for the small tile).
So there isn't much that you can change from your side apart from the available options it seems.
I am looking to create a custom rounded frame for an application window (border-radius and shadow)
From a performance point of view, what would be the best technique for this?
a. Use regions (SetWindowRgn) for the rounded application window and a layered window (UpdateLayeredWindow) for the shadow.
b. Use layered windows for both the rounded application window and the shadow.
The docs for UpdateLayeredWindow specify:
For best drawing performance by the layered window and any underlying
windows, the layered window should be as small as possible.
I am asking this specifically for the application main window, so a large window that can have a high complexity and is most of the times visible on the screen.
Should I go with regions or layered window for the application window? Which one would be lighter on the CPU/memory?
SetWindowRgn disables DWM for the given Window. DWM ist the component that is responsible for performantly drawing the Window frame using the available graphics hardware. That should pretty much rule out SetWindowRgn. Also, SetWindowRgn produces very "ancient" looking results because antialiasing is not possible. A pixel can be either fully transparent or fully opaque.
For best drawing performance by the layered window and any underlying
windows, the layered window should be as small as possible.
I believe that in 2018, this hint is less relevant. The documentation was written 18 years ago when the hardware was way more limited than today.
Still, UpdateLayeredWindow is not the fastest way to draw custom window frames, especially when you have to update the bitmap often (e. g. during window resize). The bottleneck is that these updates have to go from system memory to graphics memory. To minimize window size, create four small windows which are only large enough to draw the borders/corners of your window. This trick is pulled by Visual Studio for instance. Using Spy++ one can see 4 instances of "VisualStudioGlowWindow" which are layered windows that are just 9 pixels wide/tall (on my system):
If you want maximum performance, you may also look into Direct Composition, combined with the WS_EX_NOREDIRECTIONBITMAP extended window style, as explained in the article "High-Performance Window Layering Using the Windows Composition Engine". This technique requires Windows 8 at least.
Todays displays have a quite huge range in size and resolution. For example, my 34.5cm × 19.5cm display (resulting in a diagonal of 39.6cm or 15.6") has 1366 × 768 pixels, whereas the MacBook Pro (3rd generation) with a 15" diagonal has 2880×1800 pixels.
Multiple people complained that everything is too small with such high resolution displays (see example). That is simple to explain when developers use pixels to define their GUI. For "traditional displays", this is not a big problem as the pixels might have about the same size on most monitors. But on the new monitors with much higher pixel density the pixels are simply smaller.
So how can / should user interface developers deal with that problem? Is it possible to get the physical size of the screen? Is it possible to set physical sizes instead of pixel-based ones? Is that still a problem (it's been a while since I last read about it) or was that fixed meanwhile?
(While css seems to support cm, when I try here it, it is not the set size).
how can / should user interface developers deal with that problem?
Use a toolkit or framework that support resolution independence. WPF is built from the ground up to be resolution-independent, but even old framework like Windows Forms can learn new tricks. OSX/iOS and Windows (or browser if we're talking about web) itself may try to take care the problem by automatic scaling, but if there's bitmap graphic involved, developers might need to provide different bitmaps such in Android (which face most varying resolution and densities compared to other OS)
Is it possible to get the physical size of the screen?
No, and developers shouldn't care about it. Developers should only care about the class of the device (say, different UI for tablet and smartphone), and perhaps the DPI to decide which bitmap resource to use. Vector resource and font should be scaled by the framework.
Is that still a problem (it's been a while since I last read about it) or was that fixed meanwhile?
Depend on when you last read about it. Windows support is still spotty, even for the internal apps itself, and while anyone developing in WPF or UWP have it easy, don't expect major third party apps to join soon. OSX display scaling seems to work a bit better, while modern mobile OS are either running on limited range of resolution (iOS and Windows Phone) or handle every resolution imaginable quite nicely (Android)
There are a few ways to deal with different screen sizes, for example when I make mobile apps in java, I either use DIP(Density Independent Pixels; They stay at a fixed size) or make objects occupy a percentage of the screen with simple math. As for web development, you can use VW and VH (Viewport Width and Viewport Height), by adding these to the end of a value instead of px, the objects take up a percentage of the viewport. For example 100vh takes 100% of the viewport height. Then what I think is the best way to do it, but time consuming, is to use a library like Bootstrap that automatically resizes elements, even when the window is resized. W3Schools has a good tutorial on bootstrap and more detailed explainations on any of these options can be looked up with an easy google search.
The design of the GUI in today display diversity era is real challenge. I would suggest several hints, mainly about the GUI applications design:
Never set or expect constant pixel size of the text - the user can change it from the system settings of the OS. Use some real-world measures for the text and check its pixel size when drawing. Provide some way to put the random size text in the boundaries of the window.
Never set or expect constant pixel size of the GUI widgets. Try to position them on the window in some adaptive way - according to the size of the window. Most GUI widget toolkits today have such instruments.
Never set or expect constant pixel size dialog windows. Let the OS to choose the size for you and then use what you get (X). Or, if you need to set some size and position (Windows), define it as a percent of the screen size.
If possible use scalable image formats for the icons. SVG is great for icons actually. Using sets of bitmap icons with different sizes is acceptable, but highly non-optimal as memory use and still will not provide perfect scaling in most cases.
Developing using Matlab 2014b's GUIDE, some of my GUIs have elements with units specified as "characters". Depending on the screen magnification level in Windows 7 (Control Panel>Appearance>Display) the GUI will look very different, with elements scattered. Shouldn't using characters as the unit type make adapting to the screen magnification a piece of cake, since the system character size would change I believe?
I'd rather not need to hard-code the units as pixels or etc, so that the GUI is happy being used on Windows/Linux/Mac. Anyone have any experiences/ suggestions with this?
I have found it is easiest to use pixels. You can then get the current window size and set things as percentages (from variables) of the real pixel dimensions. This is nice when you want to make sure there is a minimum or maximum panel or item size that can be resized or scaled within a range.
If you put this code in the resizeFcn() it should be good.
i am building windows store app. I am using windows 8 and WPF with visual studio .net 2012.
UI of this application should be scalable to different screens. I have created a page where the controls (buttons, images, texts) fits correctly when running the app on simulator with resolution 1920 x 1080 for 10.6" screens. The problem is that when i change resolution, controls do not behave correctly
when resolution or screen sizes are increased (ex. 1920 x 1080 for 23" screens) empty spaces are created on the page;
when resolution or screen sizes are decreased (ex. 1024 x 768 for 10.6" screens) controls sizes are increased too and some of them are not visible in UI because they are displayed too far in bottom.
Is there a way to build "scalable" store app which are independent of screen sizes or resolution? Control sizes and font sizes should increase and decrease when resolution change or from one screen to another but all of them should fit in the space and shouldn't create empty areas.
Any help would be very appreciated.
thank you
This MSDN article discusses the guidelines for scaling to screens.
it touches on Screen size, Screen resolution, and Aspect ratio. It provides a table which shows best practices recommended for apps that use scale-to-fit functionality and it touches on adaptive layout. there is a reference to [Guidelines for layouts] at the end of the article as well.
Hope this helps!
http://msdn.microsoft.com/en-us/library/windows/apps/hh780612.aspx
joelcitizen