Very large images will not render in Google Chrome (although the scrollbars will still behave as if the image is present). The same images will often render just fine in other browsers.
Here are two sample images. If you're using Google Chrome, you won't see the long red bar:
Short Blue
http://i.stack.imgur.com/ApGfg.png
Long Red
http://i.stack.imgur.com/J2eRf.png
As you can see, the browser thinks the longer image is there, but it simply doesn't render. The image format doesn't seem to matter either: I've tried both PNGs and JPEGs. I've also tested this on two different machines running different operating systems (Windows and OSX). This is obviously a bug, but can anyone think of a workaround that would force Chrome to render large images?
Not that anyone cares or is even looking at this post, but I did find an odd workaround. The problem seems to be with the way Chrome handles zooming. If you set the zoom property to 98.6% and lower or 102.6% and higher, the image will render (setting the zoom property to any value between 98.6% and 102.6% will cause the rendering to fail). Note that the zoom property is not officially defined in CSS, so some browsers may ignore it (which is a good thing in this case since this is a browser-specific hack). As long as you don't mind the image being resized slightly, I suppose this may be the best fix.
In short, the following code produces the desired result, as shown here:
<img style="zoom:98.6%" src="http://i.stack.imgur.com/J2eRf.png">
Update:
Actually, this is a good opportunity to kill two birds with one stone. As screens move to higher resolutions (e.g. the Apple Retina display), web developers will want to start serving up images that are twice as large and then scaling them down by 50%, as suggested here. So, instead of using the zoom property as suggested above, you could simply double the size of the image and render it at half the size:
<img style="width:50%;height:50%;" src="http://i.stack.imgur.com/J2eRf.png">
Not only will this solve your rendering problem in Chrome, but it will make the image look nice and crisp on the next generation of high-resolution displays.
Related
We are using a png/8 sprite on a client's website. He is reporting the image is appearing distorted for him and on other computers on the company.
Here's how it should look:
http://i.imgur.com/wfV7ReR.jpg
And here is the print screen the client sent us:
http://i.imgur.com/sWKDYKU.jpg
I have tried donloading and exporting it again, uploading again. The problem is: On our computers it looks fine, so it's hard to test it. Our client is viewing it in IE: 11 and Google chrome: 41.0.272.118.
Has anyone seen this type of error before?
It may be the device-pixel-ratio is better than 160dpi; that'd throw off some CSS used for spriting.
If this shows "1" for you and a different value for them, I'd dig farther on that one. You could probably test this by hitting the site with an iPhone or newer Android device; they have >1.0 pixel ratios.
http://www.devicepixelratio.com/
Edit: this would also show up across-browsers on their end, as it's tied to the hardware, and not IE11.
My bet in that case is the PNG is somehow broken.
graphicdesign.stackexchange.com might be more useful; I don't know if this is fixable in CSS. (Might be; look for hacks around image backgrounds as well.)
Looking around, if you have Photoshop, you might try saving the original image, then creating a copy and changing this setting:
Image -> Mode -> Check "RGB Color"
Alternatively, try opening the image in pixlr.com, change anything however slightly, then save and use that one.
My strong suspicion is something in the way the PNG/8 is saved (maybe the alpha channel) is the issue, not any CSS you've written. Good luck!
I'm planing to create a blog and I'm thinking about how to serve images in the best possible quality without affecting loading times for mobile devices too much.
My content column is aprox. 768 display points wide and I'm posting screenshots using a retina Macbook so the images will be at least 1500px wide. Other Retina/HIDPI users should see the version best for them.
Is there a recommended best practice for this case? I'm talking only about content images (<img />); no CSS backgrounds. A true WordPress solution that serves images based on the uploaded hires images would be great.
I have used adaptive images in the past but it does not distinguish between HIDPI and normal clients. Other solutions serve for retina but not for different screen sizes.
No, there is no good method for doing this. This isn't a fault of WordPress, but of the state of the web in general. HiDPI on the web is currently a big hack, basically, and the web has not yet adapted to it properly.
Basically, there's no good way to specify multiple resolution images in the HTML in a way that the browser can then use to determine the proper image to show. CSS works, but only if you're using images as backgrounds. If you're dealing with IMGs, then you have to rely on Javascript to do the job, and that has various downsides depending on your methodology.
In the future, when browsers have started to adopt methods for specifying multiple resolution images, then this won't be as much of a problem.
Edit: This deserves a bit more explanation.
The basic problem with using JS to do this is that it relies on a technique of image-replacement. The JS code, through whatever logic it has, finds the IMGs on the page, then replaces them with higher resolution versions from some other file. No matter what method is used to do this, it has two major downsides:
First, the initial image is loaded in low resolution, then loaded again in high resolution when the image is replaced. This means extra bandwidth usage, and considering most HiDPI devices are currently mobile ones, this doesn't make much sense to waste that sort of bandwidth on those devices.
Second, the image is generally first displayed in low resolution and then replaced with the high resolution image. This means that there's a second or two of showing a fuzzy image on HiDPI screens, before it "pops" into focus as the replacement occurs. This is a really crappy effect to have.
Other methods exist by which you can simply serve the proper image in the first place, but they have downsides as well.
Server-side browser detection by User-Agent is a pretty crappy way to do things in the first place, and best avoided simply because there's so many different agents out there in the wild that maintaining a list of them is virtually impossible. However, if you want to go through the pain of it, this method can work.
Alternatively, it's possible to have Javascript in the browser detect the device-pixel-ratio of the browser and set that in a Cookie to return to the server. The server can then use this cookie to serve the proper resolution image. This works, but is unreliable because many mobile user agents fail to properly set and return the cookie, and even on those that do, the high-resolution images would only be shown on the second visit to the page. First impressions are low-res, which isn't good in general.
Like you can see: It's just hacks all the way down. Until the browser is capable of being told for a specific IMG that multiple versions exist, and their parameters, and then being allowed to choose for itself, then these are the only ways to do it. But, if things like the proposed HTML5 "srcset" or the PICTURE tag are implemented, then we'll have better choices.
After thinking a while about this, I have to offer two ways to approach (parts of) this problem (partly). Still: Read the answer from #Otto carefully. It has a lot of in depth details for a reason.
Javascript detection
I wrote an answer about »How to add default images« for attachments. You can alter the filter callback to always add a simple png/gif (that has just the background color) instead of the normal image or thumbnail. This would help you serving an extremely small image (maybe below 1kB - smushIt for the rescue) that the user agent/browser would cache at the first load and then simply insert for each other call to an image.
Then, simply the display pixel density with…
var dpr = 1;
if ( window.devicePixelRatio !== undefined )
dpr = window.devicePixelRatio;
if ( dpr > 1 ) {
// High pixel density pixel displays
}
…exchange the images when the DOM has fully loaded.
CSS routing
Adding stylesheets for different pixel density displays isn't that hard:
// For default/low density pixel displays only:
wp_enqueue_style(
'low_density_styles'
,trailingslashit( get_stylesheet_directory_uri() ).'low_density.css'
,array()
,filemtime( locate_template( 'low_density.css' ) )
,'screen'
);
// For high density pixel displays only:
$media = 'only screen and (min--moz-device-pixel-ratio: 2), ';
$media .= 'only screen and (-o-min-device-pixel-ratio: 2/1), ';
$media .= 'only screen and (-webkit-min-device-pixel-ratio: 2), ';
$media .= 'only screen and (min-device-pixel-ratio: 2)';
wp_enqueue_style(
'high_density_styles'
,trailingslashit( get_stylesheet_directory_uri() ).'high_density.css'
,array()
,filemtime( locate_template( 'high_density.css' ) )
,$media
);
Now you can simply switch between high/low density images - for your default images (header, logo, etc.). This doesn't work for post type attachments (again: refer to #Otto answer).
Im making a page/application that presents a wide range of products. One view contains a lineup of about 130 products, eash represented by a png-image, the size varies from 33Kb to 150Kb.
The lineup can be scrolled horizontally whith the users scrollbar or custom controller, and when you hover each product I use som css-transistions to fade out all products except the one hovered, and to enlarge it.
It works perfectly smooth in Safari and decently Firefox, and in Chrome as long as I keep the image count-down. But the more images i try to add, both the scrolling and the transistions progressively gets slower until it's almost imposible to work with.
Is this some cache.problem in chrome? Is there any way around it?
I've tried to preload the images, but the problem isn't the loading time og the image, its the performance that seems to halt due to the sheer number of images.
You can combine all your little images in one big image, and load ONLY the big image, so you do only ONE HTTP request. For display you must set the offset (background-position property) of every image using css.
Tutorial
i'm buildling a website and I want to create a translucid menu. I know that .gif image types enable transparency, but from my experience, not translucidy(anything between being transparent and opaque) - by default it seems to set the opacity to 100%, ie a solid image without any translucity/transparency.
I'm not sure if the issue is with the file type, or with how I'm exporting my menu. If it's worth anything, I'm using Fireworks to create and export my menu.
As is, I'm exporting my seperate files for my menu as .pngs, which seem to support translucent images, but I know that I'll be wanting to reduce the file size of these images soon, so is there a better alternative to getting a semi-transparent image other than using the .png file type?
Thanks,
Patrick
I'd say PNG is probably the best bet. The more modern browsers (read: not IE6) understand the 8-bit alpha channel it provides, whereas GIFs just have the transparency key.
Often these days, the bottleneck on sites isn't the size of the image (either in dimensions or in data) but rather the number of requests that it takes to load a page. More modern website designs try to pack as many images into one using techniques like CSS Spriting (woot.com, most of google). The other bottleneck is often not setting caching up correctly, forcing return visitors to reload a bunch of stuff.
You'll see google's various pages caching everything it can, and reducing the number of things a single page needs to download (combine all Javascripts into one, all CSS stylesheets into one) so that the browser is make 2 and 3 requests instead of 15-20.
I'd go with PNGs, and look into CSS sprites and caching as an alternative optimization.
See here for an example of an image sprite used on google's homepage.
I have a flex app I am scaling using systemManager.stage.scaleMode=StageScaleMode.NO_BORDER; for the most part it works well except for my bitmap data (mostly png's from the designers).
I can set the mx:image tags to smoothBitmapContent=true and that works great for everything except my mouseover objects. When I do a mouseover, the source is being changed from one embedded image to another embedded image. I have tried several (many) online "smoothimage" classes, and tried to write my own, I have tried to reset smoothBitmapContent every chance I get but still no dice. It seems to mee that because I am scaling at the app level, that the flopped out bitmap is not getting smoothed when it renders.
How to keep things smooth? Perhaps there is a flag to tell Flex to smooth stuff when it scales it?
So the easy answer (that works for me) was to instead of changing the image.source from one embedded png to another, was to use two images and flip flop image.visible between the two... Granted that adds two extra objects to the screen, But for some reason they all stay smoothed and scaled that way, where as before switching sources was going from smooth to jaggidy and un-readable.
Josh