I'm using an iterator in Quartz Composer to render Images for multiple displays. How do I combine this with Syphon Servers?
I think this is the wrong approach. Using just one syphon server, you should render images for each display in a single extra large texture. I use the Billboard patch to control the placement of each display's intended image. Then there are software and hardware solutions for splitting an extra wide image across multiple displays.
Related
I'm developing simple mobile game for android using cordova. The game is the simple Hidden Object game where player has to find requested objects on the scene. One of my levels had very slow performance. More powerful devices worked fine. I've tried force GPU rendering using translateZ hack and got huge performance boost but, on low-end devices started wired rendering artifacts.
This screenshot is from Meizu U10. The background consists of 3 layers with position absolute, z-index 1,2,3. Objects to find (Cow, chicken etc) has same position absolute and z-index depends from background they are related to. If run game in browser on the same device, there is no artifacts and performance just great. Google did not give me any useful clues, so i will be very appreciate any guesses and tips.
Using SVG can be an option you might need to consider, specifically inline SVGs.
Using inline SVG is beneficial to the performance of a website because
it eliminates the HTTP request needs to load in an image file. Since
no file needs to download, this results in smaller loading times for a
page. This makes your website appear faster to visitors, improving the
user experience.
You should really consider using a webGL rendering engine such as PixiJS if you want to have performance in your games. You would just have to convert your images into textures.
Can anyone help me understand why my images are coming out rotated? The images themselves are vertically oriented, but they appear sideways in the web page.
sorry, here is the link
If you're on MacOS or iOS then photos that were taken with incorrect orientation data (because your phone had rotation lock enabled for example) then Finder, Lightroom, Apples Photos app and others can automatically detect this and rotate the photos without changing the original file. But a (non Apple) web server or even Windows, won't recognise these properties out of the box, as these non-destructive edits are stored separately.
If your going to run into this a lot I would recommend installing either a bootstrap compatable extension to batch edit photos server side, or run a batch conversion on your computer or mobile device that "physically" rotates your photos and re-saves the change to the file itself.
This last option is somewhat destructive if you overwrite jpg files as jpg with a compression less than 100% (which is usually the case.)
If you resize photos before uploading to your server anyway the rotation data should already be applied and I advice you to do all edits in one go so the photos only get re-saved once, and not deteriate each time you resave.
One small power tip: you can give very large photos a much higher jpg compression than small photos, but get photos that are, sharper, bigger and with smaller file sizes than if you had prepared a medium downscaled copy that requires a low compression (aka high detail level) setting to still look good. This neat method also makes sure your photo galleries are retina compatable and future proof.
I know that there are many devices that uses the favicon from the website in different ways...
On these favicon generator websites you can easy put an image there and the website will do the rest (generating several scaled images for certain devices)
If i want to cover ALL devices (Apple, Android, Windows Metro Tiles, and more) i would have to store 26 images (that are ALL the same picture just with different sizes)
And i would have to add 19 lines of HTML code to refer the certain devices to the certain images.
Is there a way to use just 1 file for all sizes?
I know that an ICO-File can contain multiple dimensions of an image.
I also know that a SVG-File doesn't depend on pixel resolution at all because it's vector based. (So a SVG can support EVERY imaginable size)
I could imagine to implement all sizes of an image to just a ICO or a SVG file where every device can pick it's optimal size.
Is that possible?
Its not exactly possible to serve different sized PNGs' in a single file.
SVG file would be the best hope here but.. Browsers today don't like them
Alternate option would be to use a tool that manages this process automatically.
I had the same frustration as you, so I simply came up with this tool called MakeFavicon
It helps create multiple favicons with predefined sizes and filenames at a desired folder, and also creates config files such as browserconfig.xml,manifest.json, partial view of HEAD to be included with relevant info.
I'm using it as a part of my Visual Studio build process and it works seamlessly to update all these files on every build.
Here's link to its example usage.
Suppose I am using a DIV element for which I can either add a background image or can replicate the same style creating a CSS3 gradient. Now, for Phonegap applications (where all the image files reside in the device itself), which option is better to go for.
I am asking this because I saw somewhere that the gradients takes some computation time where using image may create a loading time issue. But for Phonegap apps, the image load time issue may not be there. So, maybe just using the image be a better option here?
According to an article on the Webkit Wiki, images perform better:
Sometimes it's tempting to use webkit's drawing features, like -webkit-gradient, when it's not actually necessary - maintaining images and dealing with Photoshop and drawing tools can be a hassle. However, using CSS for those tasks moves that hassle from the designer's computer to the target's CPU. Gradients, shadows, and other decorations in CSS should be used only when necessary (e.g. when the shape is dynamic based on the content) - otherwise, static images are always faster. On very low-end platforms, it's even advised to use static images for some of the text if possible.
Source: https://trac.webkit.org/wiki/QtWebKitGraphics#Usestaticimages
Of course, you have to balance that CPU time with the extra time it would take to load the image from the server. Also, for Internet Explorer, filters are extremely slow, especially if you have many on one page.
I don't have much experience with the sprite approach to images (http://www.alistapart.com/articles/sprites). Anyone care to share some pros/cons of sprites vs. old-school slices?
The main advantage of sprites is that the browser has to request less pictures from the webserver. That reduces the number of HTTP requests and makes it possible to compress the parts of the design more effectively. These two points also represent the disadvantages of sliced images.
Here you can see some good examples how sprites improve the loading speed of web pages:
http://css-tricks.com/css-sprites/
Pros:
It's far easier on the server to serve a single large image than many small ones.
It's (slightly) faster for a web browser to load such an image.
Browsers only load images as they needs them - if you are using multiple images in a rollover, the browser would "pause" the first time you roll over the element. This can be solved using sprites, because there is only one image to load.
Cons:
It's kind of a pain to code (more so than using multiple images at least)
One often overlooked downside of using CSS sprites is memory footprint:
https://web.archive.org/web/20130605000516/http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/
Unless the sprite image is carefully constructed, you end up with
incredible amounts of wasted space. My favourite example is from WHIT
TV’s web site, where this image is used as a sprite. Note that
this is a 1299×15,000 PNG. It compresses quite well — the actual
download size is around 26K — but browsers don’t render compressed
image data. When this image is downloaded and decompressed, it will
use almost 75MB in memory (1299 * 15000 * 4).
When sprites get loaded into the browser, they are stored uncompressed. A 26 KB file can uncompress to take up a whopping 75 MB of RAM. You should be mindful of using sprites with very large dimensions.
There's also the issue of what happens in browsers with poor CSS support (legacy browsers). The sprites may end up totally broken.
Sprites
Pros:
Less HTTP connections to the server
Faster loading on broadband
Cons:
No encapsulation: If you want to change one image, you have to change the sprite
It is difficult to setup individual images in CSS without a tool
Don't degrade: If the browser don't support CSS, you are in trouble
CSS Sprites:
Pros:
Graceful degrade in unsupported browsers (text can be shown when background images for links are not allowed)
Fewer HTTP requests
Each image has a separate overhead like color table so image slicing will be having more overhead than CSS sprites
Cons:
Poses a problem if images are turned off in the browsers (rare case though)
Image slicing:
Pros:
User perceives a faster load since loaded piece by piece.
Load on demand like when the user places his mouse on the image
Cons:
The webpages might have a large size on the client side even thought it might not be the case on the server side.
The main drawback of sprites is it makes it hard to read/maintain/modify your CSS. It can be difficult to remember the exact pixel offsets within the sprite.
pros using sprites :
since it is using 1 images for all, it require less load on http server.
cons:
- hard to code. you must know the coordinate each images inside sprites so you can display it correctly. once you change the size of the image, you need to adjust all ...
- big images could creates long waited page to display. while using images, user with slow internet connection can see one by one.
best practices.
use it for example roll over images.
Look into using a CSS sprite generator (we use SmartSprites). That way you can do slices locally, and have your build process generate a spritemap. It's the best of both worlds.
Also is SmartSprites isn't for you, there's definitely others, however I like it because it reduces the amount of work up front AND during changes.
Cons
- slower on older browsers/ maybe not working on them with hover effect (opera6)
- if not used correctly can get very/too huge (group them adequately!)
- tedious work to set them up
Pros
- less bytes transfered, because one big image is smaller then all individual images combined (one header/ color table)
- less http requests
I prefer going the middle ground of grouping similar images (normal, hover, selected page, the parent page of selected page) than having all the images in one file. To make these, you image slice like normal in Photoshop or Illustrator, open the files up and combine them with a shortcut key. I wrote the Photoshop script that combines images into CSS sprites. You will have multiple HTTP connections, but won't have the load delay on hover.