I've followed the answer in this post Cesium label blurred but have had no luck.
I've made sure that viewer.scene.fxaa = false and nothing seems to change. Please see my screenshot attached.
Does anyone have a fix for this?
Thanks so much!
Be wary of hard-coding something like viewer.resolutionScale = 2. There's a baked-in assumption on this line of code that the user probably has a high-DPI screen, and their browser is scaling up the webpage accordingly. Running this line of code on a system that is already using a 1:1 pixel ratio may cause it to render twice as wide and twice as tall as what the device can actually display.
Here's an alternate suggestion:
viewer.resolutionScale = window.devicePixelRatio
It's not perfect, but better than a hard-coded 2. It will attempt to get the Cesium viewer to exactly match the device's native pixels, which may not be the same size as "CSS pixels", particularly on high-DPI screens.
A value of "1" here (the default) means that Cesium's viewer canvas pixels are the same size as the webpage's idea of CSS pixels, which may be larger and chunkier than the screen's own native pixels. Higher numbers act as a multiplier on the WebGL canvas resolution, taking more graphics memory and performance. You may find that the machine you're testing this on already has a window.devicePixelRatio of 1.5 or 2.0, so the line above may not act any differently from a hard-coded 2 on your particular machine. But checking the local devicePixelRatio is better than making assumptions.
This can be fixed by adding:
viewer.resolutionScale = 2
May impact performance, but it seems fine so far.
Related
I'm trying to use a canvas element, but the height can't exceed 16384 pixels. If i try with 16385 pixels, I get a IndexSizeError in IE11. This works fine in Chrome. The canvas is used in a PDF generation, and I don't really have time to move the generation to the server.
I've googled a bit, and it seems like the size might be different based on platform and browser.
Is it the browsers assigned memory and memory settings that decide this?
EDIT: I found some information here:
Note The maximum size of the rendered area on a canvas is from 0,0 to 8192
x 8192 pixels, regardless of the size of the canvas. For example, a canvas
is created with a width and height of 8292 pixels. A rectangular fill is
then applied as "ctx.fillRect (0,0, canvas.width, canvas.height)".Only the
area within the coordinates (0, 0, 8192, 8192) can be rendered, leaving a
100 pixel border on the right and bottom of the canvas.
Seem like I can have twice the size. Maybe this is just for IE9.
The maximum area, width, and height of an HTML canvas element is dependent on the browser, operating system, and hardware available. Unfortunately, browsers do not provide a way to determine what their limitations are, nor do they provide any kind of feedback after an unusable canvas has been created.
It is possible to detect the canvas limitations of browser, but unfortunately not using native APIs. See my answer in the Maximum size of a <canvas> element thread for details.
The Canvas Specification states "the element can be sized arbitrarily by a style sheet", so based on this and the information you shared from the link, IE must likely be implementing their own maximum size. This seems useful, but does not provide any sources to back up the numbers shown (the favourite answer).
I am working on a map application and I have come across an issue with how my tiles are laying while scaling.
Here is a basic look at my structure:
There is obviously a lot more going on, but you get the idea. Now, I scale the Map App Sprite to zoom in. When that scaling occurs, there is a gap between each tile.
You can see the gap where 4 tiles meet here:
I am caching everything as a bitmap. For each Layer (which all extend Bitmap), I have smoothing set to true and pixelSnapping set to PixelSnapping.ALWAYS (pixel snapping shouldn't help here, but it shouldn't hurt either).
Does anyone have any suggestions on how to fix this issue?
(For the sake of completeness, the Map app is built entirely using AS3 and it is embedded in a Flex app)
Using integers for tile x,y locations and calculating those locations correctly is most likely the fix here, unless the images have seams in them!
The code that calculates and sets the x,y locations would be needed to properly pinpoint the issue in the code.
But, also if you are scaling that container sprite, you would want to ensure that you scale so that the width/height of a tile is an integer value.
For example, if you scale your sprite that contains these tiles, the widths/heights of the individual tiles might not always be integers, therefore creating those seams you see.
What you could do in that case is do your scaling by adjusting your width/height values by integer values, taking into account proportions, as opposed to using scaleX and scaleY on your container sprite.
Without seeing your code it's difficult to be sure, but it is possibly just a visual artifact due to scaling - eg: a 250px wide bitmap scaled to 155% should be rendered at 387.5px wide but thats impossible so its rendered at 388px wide - with the 0.5px part rendered as 1px at 50% alpha to give 'appearance' of 0.5px.
Ensuring scaled bitmaps widths/heights are always integers may solve it?
This looks like a rounding error.
Without code it's hard to know: it would be a great asset to you and us if posted a barebones example of your tiling class. In the process of subtraction you may very well discover your solution.
I'd offer that you should test what happens when you scale and algin four 100x100 bitmap images at various fine grain steps, to detect if it's a Flash rendering issue or a defect in your class.
In the case of responsive css design, let's assume you have a couple of different-sized versions of an image and you reach a point where you have a screen width of 900 pixels.
What's the best thing to do in this case?
Case a) downscale an 950 pixels image or case b) upscale an 850 pixels image
(these values are of course fictive, I'm not talking about a particular case)
From where I standing, each one has its own advantages and disadvantages:
Using downscaling, as a PRO the image should have a better quality (at least I think so, I don't know that much about the different browser's downscaling algorithm). As a CON, the image would take longer to download, something important if you're also targeting mobile.
Using upscaling, you gain download speed, but you lose quality.
Of course, you won't upscale a 500 pixels image to fill 1000 pixels width, just as much as you wont downscale a 2000 pixels image for obvious reasons, assuming you have a choice.
But in cases where you have similar values is there a sort of rule of thumb that might help you make a decision or it doesn't really make a difference and it's up to the developer?
Or, at least, is there a factor that would weight more? For example, by using upscaling you could get a much larger benefit from the download time decrease then from the decrease in quality and viceversa.
I think you could look at it in different ways. Also, you should ask yourself some questions:
What audience are you trying to reach (Mobile (say up to max-width of 640px) or desktop (anything wider than 640px) orientated)
What is the largest image you will use (in width and height)
Are your images needed on your mobile website (i.e. can you make a simplified mobile version of your website, without losing too much of its contents?)
When your focus lies on a desktop environment as defined as above I would not bother too much about your problem. Of course larger images will take some time to load, but don't forget that most mobile browsers have two very neat features: 1. data that is retrieved by the device has first been compressed by servers (think Blackberry, Opera ...) and 2. most of the time browsers allow options for the quality of images (low, normal, high). So users can still choose what kind of quality they want, without you needing to decide for them!
I think that when you focus on a mobile audience, it is best to upscale. I don't think that your website is mobile-only though, and you want to keep your website to look good on wide-screen devices as well so I would go for downscaling! Also, don't forget to optimize your images (JPG compression with 80% should reduce the size a lot, but shouldn't hurt the quality too much).
EDIT:
So I've been thinking about this and there is something else you can do: work with two different images. I can hear you thinking: but that doesn't sound logical, how can the browser detect the image that needs to be changed when it is not loaded yet (would be stupid to load two images). Well, here you go. (Credits go to jAndy in this question)
jQuery code (note that I linked to my own webspace. This fiddle will thus not keep working for eternity!)
$(document).ready(function() {
$("#jsDisabledMessage").hide(); // HIDES MESSAGE THAT TELLS USER TO ENABLE JS
if ($(window).width() < 480) {
$("img").attr('src', function(index, src) {
return "http://bramvanroy.be/files/jsfiddle/8mZnk/" + this.getAttribute('data-path') + "-mobile.jpg"; // FOR MOBILE DEVICES
});
}
else {
$("img").attr('src', function(index, src) {
return "http://bramvanroy.be/files/jsfiddle/8mZnk/" + this.getAttribute('data-path') + "-not-mobile.jpg"; // FOR DESKTOP
});
}
$("img").show();
});
So, what happens:
Browser reads HTML
Browser is not tempted to find image (and images are hidden by CSS anyway)
jQuery finds the appropriate URL (depending on screen size) and adjusts HTML accordingly
jQuery shows the images
When JS is disabled, a message will be displayed telling the user, the requested images cannot be displayed.
I hope that this is something in the right direction.
I've just gotten into web development seriously, and I'm trying to make a page that appears the same physical size ( in inches ) across all browsers and platforms
I believe a combination of percentage values and inch values can make a consistent UI.
my own system is a 15.4 inch screen with 1920x1200 pixels i.e. 144 DPI.
Here is the most simple HTML code that fails to appear the right size on any browser except FireFox (Tried on Chrome 3, 4, Opera 10.5, IE7)
<html><head>
<body>
<div
style="position:absolute; width:2in; height:1in; border:1px solid" >
hello world</div>
</body></html>
Chrome, Opera and IE render a .67 inch box ( They seem to be assuming a 96 DPI screen )
I am running Windows XP, but I see no reason why that would make a difference. Similar incorrect rendering on other machines I have tested.
I thought when I say "1in" in HTML it means one actual inch in the real world....
How do I handle this?
Thanks in advance,
Vivek
Edit :
in 2006 I developed an activex control which did live video editing for a website, in 2008 we started seeing lots of Vista use and higher DPI screens which made the UI unusable, I reworked the application so that everything scaled according to DPI, since then everyones happy that they don't need glasses to use the feature....
The whole reason that Win7 and Vista have this "DPI scaling" mode is to allow non-DPI aware apps to display ( but since it basically scales up the app's canvas, the apps look blurry ).
I can't believe that calling GetDeviceCaps() or the X-Windows equivalent is harder than hardcoding 96 DPI. Anyway it wouldnt affect any page that measures in pixels....
Can't be done. Period.
Screens are a grid of pixels and that is the only unit recognized by the physical display. Any other measurement must be converted to pixels for display.
This conversion is done by the operating system's graphics subsystem, which has an internal "DPI" setting - quoted because it's arbitrary and does not necessarily correspond to the actual physical DPI of any real-world device. Windows, for example, defaults to 96 DPI regardless of the display that it's connected to.
When you look at a page with something with a height of "1in", your machine looks at it, calculates that, since it's set for 144 DPI, "1in" means 144 pixels and makes it 144 pixels tall, regardless of the physical distance that those 144 pixels will occupy on your display.
When the typical Windows user with the default 96 DPI setting looks at it, their computer calculates that "1in" = 96px and makes it 96 pixels tall, again regardless of the physical distance that will correspond to those 96 pixels.
And you know what? This is a good thing. It means that a user with poor vision can lower their video driver's DPI setting and everything sized in inches, cm, point, em, or other 'real-world' units (i.e., basically anything other than percent or pixels) will get bigger so that they can see it more easily. Conversely, those of us who don't mind small text can artificially increase our DPI settings to shrink it all and get more onto our screens.
The tyranny of the printed page, forcing things to be a certain size whether we like it or not, is no more. Embrace the power this gives your users over their experience. Don't try to take that away - you won't succeed and you'll just annoy people in the process.
Instead of giving the size in px you just give it in percentage . so that it can fit on any screen based on the percentage .
I don't really think you can, to be honest.
The DPI of the screen is determined in hardware, i.e. a 15.4" Screen with 1920x1080 resolution = 144DPI.
Why do you need the site to appear as the same physical dimensions? Surely the same size, proportional to the screen is enough? i.e. if my resolution is 1920x1080, your site should take up 50% of the wide. If I'm using 1600x1050, it should take up 60%?
In short — you can't, at least for use on screen.
Using real world units depends on having clients knowing the correct DPI for the system. Between clients that don't bother, and systems which are not configured correctly, it is a hopeless situation.
If you want something to scale so it is a reasonable size for the users system, then you are likely best off using em units to scale based on the user's font size. This still has problems where the defaults are not suitable and the user hasn't changed them, but it is right more often than physical units.
I was wondering if anyone has done any tests with background images. We normally create a background that repeats at least in one direction (x or y or both).
Example
Let's say we have a gradient background that repeats in X direction. Gradient height is 400px. We have several possibilities. We can create as small image as possible (1 pixel width and 400 pixels high) or we can create a larger image with 400 pixels height.
Observation
Since gradient is 400 pixels high we probably won't choose GIF format, because it can only store 256 adaptive colours. Maybe that's enaough if our gradient is subtle, since it doesn't have that many, but otherwise we'll probably rather store image as a 24-bit PNG image to preserve complete gradient detail.
Dilemma
Should we create an image of 1×400 px size that will be repeated n times horizontally or should we create an image of 100×400 px size to speed up rendering in the browser and have a larger image file size.
So. Image size vs. rendering speed? Which one wins? Anyone cares to test this? With regards to browser rendering speed and possible small image redraw flickering...
The rendering speed is the bottleneck here, since bigger tiles can be put into the browser's cache.
I've actually tried this for the major browsers, and at least some of them rendered noticeably slow on very small tiles.
So if increasing the bitmap size does not result in ridiculously big file sizes, I would definately go with that. Test it yourself and see. (Remember to include IE6, as still many people are stuck with it).
You might be able to strike a good balance between bitmap size and file size, but in general I'd try 50x400, 100x400, 200x400 and even 400x400 pixels.
I found out that there may be a huge difference in the rendering performance of the browser, if you have a background-image with width of 1px and repeating it. It's better to have a background-image with slightly larger dimensions. So a image with a width of 100px performs much better in the browser. This especially comes into play when you use a repeated background-image in a draggable layer on your website. The drag-performance is pretty bad with an often-repeated background-image.
I'd like to point out that for the cost of sending down an extra few rows (1-2 only example here) .8k - 1.6kb (if you can get away with 8-bit) more like 2.4kb - 4.0kb for 24bit
2 pixel columns more means the required iterations required to blit the background in is cut down to 1/3 for up to 1.6kb (8-bit) or 4kb (24bit)
even 1 extra column halves the blitting required down to half the element width.
If the background's done in less than a second for a 56.6k modem I reckon it's lean enough.
If small dimensions of an image have a negative impact on rendering, I'm sure any decent browser would blit the image internally a few times before tiling.
That said, I tend not to use 1 pixel image dimensions, so I can see the image clearly without resizing it. PNG compression is good enough to handle this at very little cost to file size, in most situations.
I'd put money on the bottleneck being the image download rather than the rendering engine doing the tiling, so go for the 1 pixel wide option.
Also the 24-bit PNG is redundant since you're still only getting 8 bits per channel (red, green and blue).
I generally prefer to go in between, 1pixel wide will probably make your gradient seem a bit unclear but you can do something like 5pixel width which gives enough room to the gradient to maintain consistency and clarity across the page.. but I would suggest you can add more patterns and images to a single image and then use background positioning(css sprites) to position them because download a single image of say 50kb would take less time comapared to 5 40kb images since the browser makes fewer requests to the server...
I have not benchmarked this but I'd bet that on most modern computers the rendering won't be an issue whereas you always want to save on on the image download time. I often go for the 1px type of graphics.