I am working with Unity 5, and when I add Canvas Button the button get smaller
this is how it looks like before build
Before Build to an Apk
and after build on my Lg g3:
As seen on your screenshots, the button has a fixed size in pixels. and your mobile screen probably has a higher screen resolution.
Set the Canvas Scaler to something other than
Constant Pixel Size as this Makes UI elements retain the same size in pixels regardless of screen size.
scale with screensize would in this case be more fitting. As it Makes UI elements bigger the bigger the screen is.
as per Unity Documentation
Related
This question relates to web development.
I'm going to start by apologizing for the horrible title but I wasn't sure how to title this. CSS pixels and how they interact with screen resolutions confuse me a bit already, when you add "intermediate pixel layers" and image drawing it's even more nebulous. So here's my actual question:
Let's say that we have an image set to display as 2x1 (css pixels) on a web page. And we instead feed it a 4x1 image (rasterized). The browser will fit this image to the 2x1 css pixels we specified earlier. But, would we technically be able to see all 4x1 pixels on a setup where 1 CSS pixels = 2 device pixels? Or would it instead resize the 4x1 image to 2x1 then display each pixel twice? And does this change on a per browser/device basis?
Bonus points: How does this play into accessibility tools that zoom into web content for the visually impaired? (if at all).
Answering my own question. The short answer is YES browsers will show different amounts of detail based on screen resolution.
CSS pixels ARE NOT screen pixels. If an image is 600x600 pixels and you decide to display it in a CSS-defined area of 300x300 (img:{width:300px;height:300px}), it could display as 300x300 screen pixels or it could display as 600x600 screen pixels. Which of the two it is will depend on the end user's OS screen resolution.
Example:
I created a 4x1 pixel png image:
I added this image to an html page and sized it with a img:{width:2px; height:1px;}. For good measure, I also added a blue div with div:{width:2px; height:1px;} bellow it.
I then set the "css resolution" of the page to half that of my OS screen resolution (If the OS was set to 2000x2000 I made sure that the full html page had a css widthxheight of 1000x1000px). So each css pixel would contain 4 screen pixels.
This is how it displayed:
Both the image and the blue div are 2px wide (that's css pixels) but they display as 4 screen pixels. In the case of the blue div, it duplicates the pixels to fit the screen resolution. But in the case of the image, it displays all 4 individual pixels. In both cases, it duplicates the pixels vertically to fit the screen resolution (technically it's probably more of a stretch than a duplication, but you get the idea).
I'm not entirely sure about this but I'm assuming at this stage that all browsers act in a similar fashion.
How do we have QT Quick QML application render properly on different screen sizes?
For example screen size 800x600 and 1280x720.
So how should I build the screen so that it looks the same on both the screens?
I know we have to use Anchors and avoid X, Y fixed location.
But we need to provide Height and Width for the components and that is causing the issue for displaying the same component on two different screens.
I have read the below links:
https://doc.qt.io/qt-5/scalability.html
https://doc.qt.io/archives/qt-4.8/scalability.html
QT recommends, building two separate parent layouts sounds illogical.
Is the scaling approach is the way to go?
QML fit screen on all resolutions
Normally, when I deal with scalability it's in a smartphone environment which has much more variableness to it than your situation but I think the same principles hold.
Generally speaking, I don't think you should try to scale the logical pixel ratio of the entire user interface. I think it should stay at 1:1 where one logical screen unit (pixel) in QML equals one logical screen unit (pixel) outside of QML.
The main reason for this is you are normally going to have at least two different aspect ratios: in your case 800x600 is 4:3 and 1280x720 is 16:9. When the aspect ratios do not match, you either have to clip content or have black bars on the sides if your UI itself chooses one or the other of those aspect ratios and tries to display full screen on both (assuming you don't want to stretch the image of the UI in either direction - which almost never makes sense for a UI).
So, what I normally do is use RowLayout and ColumnLayout with fillWidth and fillHeight set appropriately on the UI itself so that appropriate interior areas of the UI stretch to accommodate greater or lesser space as the screen size changes. It's the same principle used in web apps to accommodate various window sizes.
One great way of doing this is to build the app to your desktop environment (Mac or Windows) and just resize the window and see how your layout adapts to different screen sizes. Once you've got it laying out rationally for the range of sizes you have to deal with, then you can build for your target environment and it should run fine.
I'm trying to make a window adjust to it's optimal size and need to do so quite often. The window is able to dock along the edges of all the screens attached to the computer but when I move to a narrow screen, the window has it's width reduced to 2/3 of the screen's width; as per the documentation.
I can't calculate the size of the window, on my own, beforehand and have to rely on Qt doing the right thing.
I have fairly limited options regarding refactoring (as in pretty much none).
The correct version is from a screen that's 2560 pixels wide.
The narrow version is from when the window is placed on a screen that's 1080 pixel wide.
As you can see, three of the icons are missing in the narrow version.
The size of the window is not some fraction of the screen. It has to be exactly big enough to contain it's content; no more nor less. The problem is not setting the size of the window as such: it's making sure that the size does not adjust itself to narrow screens when adjustSize is called.
I am currently building a minesweeper game which has three different game modes. Harder mode has more objects and a bigger window size. When I try to switch back to a simpler mode, the size of the window will not resize to a smaller window, which will make the layout look terrible.
Before it looks like this:
After switching from a harder mode, the layout will be like this(which remains the size of the harder mode):
So what can I do to set those windows to suitable sizes? Or what can I do to set a default window size for each mode? Thanks
There is a few things you should look into:
Size policies. Size policies of the individual widgets dictate how they might shrink or be expanded vertically and horizontally. With the right policies, elements like the icons and scores at the bottom will stay reasonably sized in all geometric configurations. Depending on how you realized the playing field, you can also use size policies there to ensure that elements don't grow too big.
Spacers. A horizontal spacer element in the middle of your bottom bar will help keeping the icons and scores small and in position. It will eat up the additional space.
QWidget's adjustSize() method. You can call it whenever your playing field changes. If your playing field does not work with size hints, but absolute sizes, you can call resize() on the playing field widget, and then. if necessary, adjustSize() on the main window.
Is there any way to get the window aspect ratio in a css media query? I have found the device-aspect-ratio, and device-pixel-ratio, but it seems that it is all possible to get several breakpoints based on pixel size and number of pixels and also device width. Is it not simpler to make website relative to the browser window because the browser window spans over the whole device on mobile phones (for now) but on PC you can resize your window to your wishes?
So is there any workaround or do I need to do some server/client side programming?
Thank you enigma. English is not my first language.