I am looking to make a website dynamically scale its assets (png/jpg) and output the appropriate css for three sets of resolutions: 540p, 720p, 1080p
Currently we have assets created for each resolution, so thats 3 sets maintained manually, ideally I want a Jenkins/hudson job to create the assets (by scaling from the highest resolution asset set, maybe use imagemagick commandline) and then generate CSS to make the resolution layout possible.
This is clearly not an old or unique problem, I am wondering what is the best approach to take for this?
The webpage is intended for low computing power embedded devices, which have limited capability, albeit HTML5 supporting. The solution has to be a server side creation of assets and CSS scaling as we cannot rely on the devices to be able to cope with much scaling.
Look forward to your thoughts and replies.
Cheers in advance.
Not a real solution, but rather a work-around which is working well and is easier to maintain:
Replace PNGs with SGVs. Take the highest resolution version and use something like http://vectormagic.com.
For JPGs take the highest resolution version, but compress it heavily and use something like ImageOptim. This works well for:
Browsers are nowadays very good at resizing higher resolution images to smaller ones.
Since the pixel density is so high if you are using the full size, the compression (artifacts) will be much less visible. And if your browser is scaling down, artifacts will be less visible because of the smoothing your browser applies.
File sizes will be bigger, but not much, since you can use a higher compression and it's getting more efficient with the image's size.
Reference: http://www.fngtps.com/2012/reasonable-ways-to-use-high-resolution-images-on-retina-displays/
Related
Let me start off by stating that I realize the arguments against doing CSS Sprites for large images. I even asked a question about why that could be considered a bad idea (and added an answer of my own). Now that we've had that talk...
I'm going to be making a large CSS Sprite-map. For the process of making this sprite-map, it behooves me to know what (if any) limit exists for the height and/or width of a sprite image in order for browsers to properly process it.
The ultimate reason behind this question is a debate over whether to lay out the sprite images in a grid or in a single row/column. For example: is it necessary or beneficial to do 4000 x 3000 instead of 400 x 30000?
Edit: The sticking point here isn't about what size images can be, but rather what size browsers can process for sprites. Given the lack of detail thus far, I'm moving forward with generating the single-large-column sprite. I'll post details of my experiences as an answer once that is complete.
Sometimes it's more of a matter of download time. Since browsers can use multiple connections to download files, a huge image can take longer to download than a few smaller ones.
If your image is so big that it's slowing down page load maybe it's time to consider several smaller sprite images.
Direct-X 9 has a size limit if 4096 pixels, so any Internet Explorer filters applied to these elements will crop them at 4096 pixels.
See: IE display transparency bug on height > 4096px?
In practice, this seems to work with no problems in Firefox 5+, Chrome, and IE7+ for a sprite image of 400x16560.
The potential issues of IE's directx rendering engine failing on images over 4096px do not create problems in IE7 or beyond; we have no method or need to test IE6 for our current project.
The one place that we experienced problems with really large spritemaps is on mobile platforms. Android devices handle them reasonably well, but iOS devices break down pretty badly, and in a strange way: They shrink the image down to fit within the dimensions they accept. So our CSS works perfectly for a small spritemap, but with no changes except increasing the physical dimensions of the spritemap image, the sprited images begin to show four times as much of the spritemap in the same html entity, with exactly the same CSS.
There is a limit in version 1.0 that is upgraded in v1.1 But still there is a limit for dimensions:
In accord with version 1.1, the scope of the 31-bit limit on chunk
lengths and image dimensions has been extended to apply to all
four-byte unsigned integers. The value -231 is not allowed in signed
integers.
Source
A funny limit is IE6.0 fails to display PNG images of 4097 or 4098 bytes in size!
But these limits are very huge in compare to what we're using in web pages.
i have a 100x100px image and i need to show that in 3 different dimensions in html,
50x50 60x60 70x70
so my dubt is if better to save img in 3 dimensions then do not use css or html width and height or if to use same img with css rules about dimensions... which solution is faster rendered ?
It depends.
If you are using the same image, Only 1 time image cache is required by the browser. So If you are displaying more than 1 type of image in the same page then dont go for multiple images. Otherwise go for multiple images.
But honestly, 100x100 if you have, It should not be a problem to load. Only in slow connections it will be problem (<128kbps). Otherwise i dont see a considerable difference.
I wouldn't worry too much about rendering speed, the main difference you'll see is in terms of image quality. Some browsers (Chrome) perform very high quality image interpolation, while others (IE, Firefox) opt for a faster algorithm that does not give as nice of a result. So you'll get the best, most consistent image quality by having the three separate image files, one for each size.
That said, since you're only scaling from 100x100 to a minimum size of 50x50 you probably don't need to worry too much about interpolation artifacts either. So I'd recommend just doing whatever is most convenient for you to implement.
And in terms of pure rendering speed, having the separate images will be faster, because no interpolation step is required in that case. In terms of initial page-load speed, however, having a single image will be faster, because there is only 1 file to download instead of 3 (or 4). As for using CSS or HTML tag attributes to set the width and height, there will be practically no difference in speed. The expensive operation is the interpolation of the image itself, and it doesn't make much difference if you specify the interpolation through CSS or through tag attributes.
Back in the day, 800 x 600 was the screen resolution to design for - and maybe 640 x 480. Then along came 1024 x 768, etc, etc, etc.
But then it gets worse: now we have not only different resolutions but also different aspect ratios.
What strategies do people use to accommodate today's ever-expanding range of screen sizes and aspect ratios?
(BTW - I was only thinking about laptop / desktop hardware, but of course there's smart-phones and tablets to consider too.)
I know this would be a somewhat controversial opinion, but I'd say it anyway: Don't
Don't design for multiple screen sizes or aspect ratios. There are of course a few exceptions: Heavy web applications like webmail clients can definitely do with more screen real estate, and are probably flexible enough to accommodate a large range of screen sizes anyway. Mobile versions of said website, with a more flexible design to accommodate the incredible spectrum of mobile screen sizes can help too for sites with high mobile volumes. However, if you stick to the so called 'desktop web', then I think we can say that 95% of the time there are more important things to care about than screen sizes, resolution and aspect ratio.
First off, lets tackle the easy one. I don't really understand why you would care so much for aspect ratio - it isn't like we care that much for the 'below the fold' nonsense anymore, do we? The web is a vertical medium - scrolling will always have a place in websites. Having everything above the magical 600px line is just stupid.
Next, screen resolution/size: Again, I find it difficult to defend.
Users with large screens do not usually maximize their browser windows, because they find that most website do not take advantage of them. While the web adjust to the user, the user also adjust to the web. Although you could argue that this is a chicken and egg problem, the fact remains that website are usually designed for the lowest common denominator. I'm not defending this position, but rather, pointing it out as the current prevailing trend in the industry.
There are certain things that simply won't work with resolution that are too high or too low. There is, for example, a small range of widths that allow people to read comfortably on screen. Any longer and the amount of movement for the eye to the next line would be annoying. Too low and the text would appear cramped. The fact that the web was designed to be resolution neutral means that paradoxically not many provisions has been made for those who wish to build fluid layouts. min-height and max-height would help, of course, but the wider the range, the more difficulties you will face. Things like orphaned elements, displaced images, backgrounds that run out, etc. are unavoidable for truly flexible sites built with today's technology.
So my opinion is that the simplest method for dealing with multiple resolutions is to ignore it altogether - with today's technology there are not many options anyway - and design for the lowest common denominator.
Watch out for high DPI settings
I think one of the most undiscussed issues facing front-end web development today is testing on high DPI systems. Everyone has learned to test and test and test on different browsers but designers/developers have not caught on to testing on different DPI settings.
High (or even low, for that matter) DPI settings break designs when fonts are scaled but images are not (which can happen), can cause images to look fuzzy/blurry, and absolutely positioned objects may not appear in the desired location (which would be devastating for CSS menus.) If nothing else, test your images at high DPI and re-render them as necessary.
This has never really been an issue until recently with the release of Windows 7 and people buying computers with high resolution monitors. First off, Windows 7 uses 96DPI as default (which is different from the rest of the computing world that has been using 72DPI as the standard. Moreover, Windows 7 will automatically adjust DPI settings and I have seen people with DPI of 150% of normal (96 DPI in Windows).
Here's a great link discussing this issue in more details: http://webkit.org/blog/55/high-dpi-web-sites/
A great cross-browser website designed with web standards is the goal but don't forget about DPI testing.
Well, trying to keep the answer not-too-long, this is what I do.
(A) Always start from the most likely used ratio/resolution
If your average joe is going to be on a modern laptop or a desktop machine he likely has AT LEAST 1024x768 (refs: w3schools elykinnovation), that gives you roughly a usable 960px width (you might want to check the 960grid system - there are a hell lot of new framework since I first wrote this).
If you users are more likely to start with a mobile device or a tablet, thing about them first.
If it's 50%-50%, it's usually better to start from small and then grow up, eg. Rock Hammer or Foundation
(B) Layout: fluid or not?
If your website could benefit from a larger width, pick a fluid design starting from this resolution. Be careful that the human eye does not like to read text over long lines, so do not abuse of fluid design; often sticking to 960px with large margins is acceptable.
You might want to add (javascript) some additional side-menus if you really have a lot more space. But design your website to work without JS as much as possible.
(C) Other resolutions
Finally it's time to check that with least used resolutions things are still acceptable.
(D) Other devices, ratios and stuff
There are not many options for different ratios; it often means you are running on a mobile, ipad, AAA or similar device.
My advice is to ... design for those devices specifically.
While writing your HTML keep in mind what you are going to need and remember to do HTML by semantic and not for design. Use properly HTML5 semantic tags if you can.
Avoid < bold > or similar tags, and properly use tags and classes that you are going to style with CSS instead.
Use a framework!
But you still can make a few different designs for very different devices. You don't have to do everything responsive /in the same design/.
There are several ways to serve a different CSS depending on the client; you can do it:
server side, checking the browser in the HTTP heading coming from the client, either with your web server or your dynamic scripting environment - be it python/django, php, or whatever else
javascript (you can easily get the window size)
html - in particular with some specific devices such as iphone
You can easily produce a generic design for small (eg. mobile) devices by following some simple rules:
1. fluid layout capable of fitting in very small widths
2. compact header/footers not too waste too much space
3. few, clear contents per 'page'
4. avoid :over effects as they won't work on touch devices!!!
If you want to go further, you have to check individual devices customizations; an example is the iphone viewport, see the apple ref library.
This is just to get you started. Experience and specific needs will drive the rest!
Your site can't work perfectly for every display. Even if you had enough hours in the day (or should I say year/decade) to design for every possible display, you'd have to do it over every time a new device comes out.
In my development, I still religiously try to avoid horizontal scrolling, and that isn't too hard with floating divs / variable-width divs. But beyond that, we really are at the "there's an app for that" cross-roads, where you need a specially designed display for specific devices.
One strategy I use is to reduce dependence on a single display -- a customer probably doesn't need to see your entire web page to do what they came to do. You can parse-out functionality to smaller/simpler web pages that scale better on differently-sized devices.
At work, I have a little more "power", as it were -- I can develop internal web apps that are "designed to run on...some specific browser, some specific display setting, etc. -- use other configurations at your own risk". This, only after getting the managers to agree that spending an extra week in development (and even more in upgrades / future maintenance) just to placate that one vegetarian at the other end of campus who refuses to use IE really isn't worth the cost. In that case, we need another Timmy, not a more flexible web app that can look good on his favorite non-IE browser.
This is a common but complex question, which unfortunately does not have a single best solution. It all depends on the kind of content that you have. You can use a fluid layout, or design your site differently for different resolutions (see http://www.maxdesign.com.au/articles/resolution/). For an example of a fluid design, check this out - http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign
I think that responsive web design is the answer to your question. Have a look at these examples and techniques...Responsive Web Design
I want to know like converting an image (gif or jpeg) to png8 using yslow smushit will increase the speed of the site performance? Will that work in ie6?
It depends on the image. PNG is suited to images with blocks of color, whereas jpeg is good for photo type images. Smushit will shave off any extraneous bytes, reducing the filesize, but if you have many small images in separate files, then you should consider spriting them in order to reduce the number of connections required to load your page.
Reducing the filesize will help, but reducing the number of files helps the most (typically).
It will make it quicker to download. PNG (AFAIK) will always be a smaller file size than GIF because it uses a better compression algorithm. Although some programs like Photoshop add a little overhead with meta data. It's also lossless, meaning you won't lose any of the image's quality.
It will work in IE6 because it supports PNG8. PNGs with 24 bit alpha transparency are not supported in IE6. There is a hack, but it's not optimal, though it is better than nothing.
There are a lot of factors involved here:
the size in pixels of the image
the size in (mega)bytes of the image
the speed at which the image can be sent to the user. This is a combination of the speed of your server and the speed of the user's connection.
the time it takes the browser to read the image and convert it to a bitmap for display
the speed of the user's computer/graphics card combination.
I'm not sure that converting images to png is going to make that big a difference to your site's performance unless you know that the bottleneck is due to the size (in bytes) of your images. If the users have a slow connection then this isn't really going to help.
Your question is very vague. I'll try answering anyway.
First of all, performance has two ends: The viewer of your site and the machine(s) where it runs on. The viewer will definitely benefit from smaller (in regard to filesize) images since it allows the page to load faster. For the server, the difference is usually not important, unless you are close to peak bandwidth of the connection.
For (non-animated) GIF images a conversion to PNG8 should be painless and beneficial, as PNG compresses much better. Also Internet Explorer 6 doesn't exhibit problems displaying PNG images with a 1 bit alpha channel (which is essentially what GIF has, too). When using an 8 bit alpha channel IE6 will have display artifacts.
Converting JPEG images to PNG will almost certainly increase the file size and won't improve image quality, so I'd advise against it.
I'm making a sprite and its reaching about 4000px in height. Is there a general size for maximum sprite height that is used within the graphics design community?
Browsers will have to decompress (and keep in memory) the whole image even if you only use very few sprites in it, and even if most of the image is blank/white.
For a desktop client you've only missed an occasion to be a good citizen by using too much memory (and browser are already sucking a lot of memory).
For some mobile client (eg. IPhone for files over 25k after degzipping), it can be more problematic, the image won't be cached at all, thus it may be better to have 2 files <25k and two HTTP request than one >25k file and a single request never cached.
Last problem, PNG compression is line-based, there is less overhead in having wide images than tall ones (though too wide could be theoretically bad in some case, since you can have only one prediction filter type per line).
Oh and also, with too much spriting, you may end with way too much different colors in the same image, and miss the opportunity for decent paletted image. Testing all combinations of this is tedious, but if you can, grouping your sprites by main colors of gradients is a good heuristic (since gradients/blur needs many different colors).
I don't think the focus should be on how big the sprite is physically (width x height) but rather how big the sprite file size is and ask yourself the question if it would be worth splitting the sprite into multiple sprites.
Quite often we split our sprites based on color so have sprites that are predominantly blue or red or yellow. That way we get smoother gradients and overall image quality while keeping image file sizes down