I find 2 people with the same problem, but all answers didn't work. So I'll try asking myself and let see what we will have, already thanks!!!
I used to use the version 4.6.1.
The project is basic some scenes, and the main scene we usually use the command
Screen.setResolution(1024,768,true) to "fit" to all resolutions and be full screen.
In the version 4.6.1, it worked fine for a while then not anymore, but for the new project we used the 4.6.4, and when we build the .exe, it don't really fit to the screen (1600x900) it take place in the middle of the screen with a black bar in each side.
We tried open a old project because we thought it could be some setting we were using wrongly, but with the same settings from the old (which is working) still has the problem!!!
We think it might be some windows update, because it is not changing windows native resolution , make any sense?
It only works on 4.0.17b (beta version).
Is there anything we could do?
See patch notes for Unity 4.6.1:
DX9: Add black bars in fullscreen mode to maintain aspect ratio.
This may have worked for you, before, depending on graphics settings and drivers.
In any case, you should generally assign a resolution that's appropriate for your monitor's aspect ratio. To calculate the aspect ratio of any given resolution, divide width by height, which you can read from Screen.width and Screen.height, or use one of the recommended resolutions from Screen.resolutions.
Related
I am using javascript svg-pan-zoom.js (https://github.com/ariutta/svg-pan-zoom) libary to zoom and pan svg in web application. Zooming in Firefox is very slow and laggy, while zooming in Chrome and IE11 works very well (tested with 5MB .svg file that presents floor plan - if file is smaller, this issue is not that noticeable). Panning is working fine. I've read many topics on this issue on forum but I haven't find any solution yet. Does anybody know what is causing this problem and how to fix it?
Example: http://jsfiddle.net/coz3fd0L/3/
Check your refreshRate option. Maybe you set a high number.
If not then you may set a low number (ex. 10 which means max 10 frames per second) and if may improve your problem.
Other than that I don't know of any other problems in svg-pan-zoom. At least if pan is smooth then zoom should be the same.
Maybe your SVG has a lot of edges/curves/nodes and Firefox is simply bad at resizing such things. Or it is bad at resizing large SVGs when matrix transform is used (matrix transform is used for zoom/pan in svg-pan-zoom).
Update: From what I see this is purely a Firefox problem (or the way it is). Just opening the SVG from your example http://imgh.us/test_51.svg takes 100% of CPU (for page scroll).
Also I did try to change matrix transform values manually (to test if it is svg-pan-zoom issue) and it is anyway very slow.
The only solution I see is to try to optimize your SVGs (maybe it is possible to make them simpler: less edges, nodes, do not render white elements...).
I am using a web application that wants to be used full screen. My screen is so wide that the application is nearly unusable full screen. More to the point, the application does deserve that much real estate. I am willing to give it ~1/3 of the width and I do useful work in the other 2/3.
I am convinced that this application uses JavaScript's screen.width to set the size of it's GUI bits. So, I am looking for a way to have my tool (my browser, for example FireFox) return a value of my choosing. Ideally, the same as window.width().
Maybe I would enable such a feature for specific URLs. More likely, I would apply this to everything.
Can this be done as an "extension"? If I need to, I can get the code to FireFox and put the feature I want in there.
What about Chrome?
You can always zoom in with ctrl + scroll. That lowers your window width.
I have been working on making our CMS export valid content for mobile devices. One of the problems we encountered was that newer devices, like the iphone4 have a higher resolution display so we needed to find a way to render the same page correctly on older devices and newer that use a 300dpi display. So far we used javascript and window.devicePixelRatio in order to get the dpi resolution, but it turns out this is not working in opera(?) and opera mobile.
Any suggestetions or maybe a defferent approach? I researched a bit but was unable to find somethig.
Thanks
I think you might misunderstand what devicePixelRatio is really telling you — surprise, a pixel is not a pixel!
When you specify a pixel size in CSS, you're not necessarily specifying a size in physical pixels. Instead the CSS px unit is actually a "device-independent pixel" (DIP), which is relative to the device's DPI:
Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values.
The reference pixel is defined as 96dpi (Windows' default DPI setting), so on your computer, it is true that 1 DIP (CSS px) = 1 physical screen pixel. Additionally, even though older iOS devices have a physical DPI of 163, they still use 1 DIP = 1 pixel. However, on iPhone 4's doubled resolution of 326 DPI, 1 DIP = 2 screen pixels, which is what devicePixelRatio = 2 is telling you.
Thus, speaking strictly of the difference between the iPhone 3 and iPhone 4, a HTML element with the style { width:100px; height:100px; } should render at roughly the same size on older devices and on the higher-DPI iPhone 4 since it rescales the pixel values.
So there is no reason you sould have to use script to account for high-DPI devices; it should just work.
Opera Mobile doesn't have devicePixelRatio yet as it is pretty much a none-standard extension added by Apple. We are considering adding this however, and may be in the next release of Opera Mobile if we do. You don't need to use JS for this however. It should work in a Media Query too with device-pixel-ratio (with vendor prefixes).
HI all,
josh3736 gave a very nice and concise answer to the css vs device pixel issue. Just wanted to add that it does seem to be an issue with large, high definition images which may need to be served more specifically for individual dpi or ppi device spec's. Searching google, I found that others are (attempting to?) using the device-pixel-ratio as a base to resize images smaller for high ppi displays, while keeping the original high def. image available for these devices and providing low def. images for mobiles without high dpi displays. That way the image is of higher quality for these devices, yet looks sized the same relative to the rest of the page across the spectrum of user devices.
The ability to zoom seems to make this more useful I gather, since a user can zoom in on high def. images and get increased detail. Of coarse this does add another layer of complexity to deal with, but it may be important to address as we have more and more new high end devices entering the markets. Still looking into this, so post back if anyone has good examples.
I have this site which was developed few years back. At that time it was developed keeping 1024x768 resolution in mind. Now a days people use much higher resolution.
I was thinking if it is possible to open the site zoomed in automatically if the resolution of user's monitor is set considerably higher than 1024x768?
Right now if I look my site on my macbook it looks like following:
I would like it to be opened up like following:
I hope I have explained the question correctly.
My browser settings are my own! It's none of the webeveloper's business to change anything in that area!
What you may be looking for however, are flexible layouts. (But that doesn't work well when you integrate pictures, as with zooming, they tend to get pixelated...)
Update
If you want to have a flexible layout that scales well and easily (also through scripting), you can consider using the em unit.
To have only a layout adjust to the screen width for instnace, you can also use percentage values.
I would like to programmaticaly determine the DPI of a user's display in order to show a web page at a precise number of units (centimeters/inches). I know it a weird request: it's for a visualization research project and it's kind of a control. We currently do it by having the user place a credit card to the screen and match a resizable div (via Mootools) to the real credit card, and voila we can get the DPI and display the page correctly.
Can anyone think of a programmatic way to do this?
If you're doing this in javascript/mootools, CSS units are your friend. You can specify sizes in inches or centimeters, or even points (1/72 of an inch). If you absolutely need DPI for whatever reason even though you can specify sizes in those units, simply size the "resizable" div you are using to a known size and calculate from the translated pixel size.
Edit:
Unfortunately, the CSS units of
points, cm, and in are not physically
correct. They are only relatively
correct. This was the first thing I
tried until I realized it wasn't
working and checked the CSS spec.. to
my dismay. – Brandon Pelfrey
That's a good point; browsers tend to fake it by assuming a default DPI (I think 72 or 96) and going with that.
Well, if you need precision sizing like you're asking for, you're out of luck. You'll never be able to get it without being able to read both the current resolution of the monitor the browser is on and the "viewable screen area" of that monitor. Ain't no way you're gonna get that via Javascript.
I suggest that you make the default assumption that browsers do and size according to the CSS units. You can then allow your users to "adjust the sizing" using the method you mentioned, but only if it's necessary. Do this with on a separate page with the DPI calculation stored as part of the users session or as a cookie.
Alternatively, once Microsoft fixes this bug, you could use Silverlight's "device independent units" for accurate scaling.
You can't. DPI is a function of the pixel resolution of the screen and the physical dimensions of the display. The latter is not available in any browser interface I am aware of.
I think that you won't get precise results - for example you can resize the picture using the monitor. I'd rather stick with the user-driven method, although you can f.e. detect screen resolution for a first estimate.
It's not possible from a browser without code running on the target computer. If you could install something on the target computer you might be able to determine enough about the monitor to calculate this.