So I understand that translate/translate3d utilizes the GPU, but for some reason it is causing large graphics to render in blocks/chunks on the iPad. I'm having difficulty finding anywhere that states a maximum width/height for images when using translate.
I'd love to be able to use css transitions on the transform property, but can't because of this issue. Even css transitions on the 'top' property are performing more slowly than using something like jQuery.animate().
Any advice on this?
I had exactly the same problem, and had a lot of success with this little CSS gem:
-webkit-backface-visibility: hidden;
I found that adding this to any element that was being animated resolved the "blocky" rendering. In some cases I also had to add it to child elements, eg. I had a large wrapper div and was using translateX to adjust the x-position. I added the magic line of CSS to the wrapper div, and also the direct children of that div (which were my content areas). Have a play around with it and you'll hopefully get it sorted out!
Related
I know this has been asked before but I'm still not convinced there's not a workaround. The reason I'm not convinced is because I managed to keep those gifs animated on a website of mine by accident. I posted this in the chat here and with help from #CarrieKendall came up with this fiddle.
This is obviously not a proper solution so I wanted to post it here for you geniuses to pick apart and try to help me figure out how I can fix this problem (in a way that preferably is not too resource heavy)?
UPDATE:
Ok, so I tinkered a bit more with the jsfiddle and came up with this:
HTML
<img class="link" src="http://i.imgur.com/jsm0x2c.gif">
<img class="link" src="http://i.imgur.com/jsm0x2c.gif">
<img class="link" src="http://i.imgur.com/jsm0x2c.gif">
CSS
#-webkit-keyframes WIGGLE {
0% { -webkit-transform: translate(0px, 0px); }
100% { -webkit-transform: translate(0px, 0px); }
}
keyframes WIGGLE {
0% { -webkit-transform: translate(0px, 0px); }
100% { -webkit-transform: translate(0px, 0px); }
}
.link{
-webkit-animation: WIGGLE 1ms;
animation: WIGGLE 1ms;
}
It's strange, but it works. An animation that does absolutely nothing. Oh and I tried replacing translate with something like scale but that didn't do the trick. This is the "purest" form of this weird bug/solution.
That said though, I'm not quite satisfied yet. I'd love it if someone more knowledgeable than me could have a look at this and try to figure what is REALLY going on that makes this workaround... work. Hopefully there's something in here that can be used, albeit in a more elegant way.
Also, I have no idea how resource intensive something like the above workaround would be, so if someone could help me measure that that'd be awesome.
The same restrictions don't occur on a desktop browser. This is specific to the implementation of scrolling that Apple has on their mobile device. It's a hold-over from their older mobile devices to make sure scrolling stays smooth, as earlier iPhones made judicious use of accelerated rendering throughout their OS.
Triggering hardware acceleration changes the render path of the page. In a non-accelerated page, the browser renders directly to the onscreen texture. When scrolling, all other execution is stopped, because the smooth scroll renderer takes control of rendering. This is not limited to just GIFs. If javascript would have changed the page content, it would also not show until the page finished scrolling.
In an accelerated page, the accelerated objects are actually sent to the compositor. The compositor puts all the layers of objects in the right place, and then creates a composite texture to put on the screen. Scrolling is actually part of the compositor's job, and since the compositor is in charge of rendering from end-to-end, animations will continue.
Unfortunately, due to the design of Apple's system compositor, there is really no 'right' way. In fact, as Apple has been making updates to iOS, there have been changes to what is hardware accelerated, and what isn't. For example, in iOS6, preserve3d no longer triggered acceleration. Supposedly,
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
should still work. In your case, I believe it works because you are using keyframes.
In terms of performance/resource impact, your page won't use any more resources than any other accelerated page.
Have you tried -webkit-transform-style: preserve-3d;, -webkit-transform: translate3d(0,0,0); or other CSS selectors that might trigger hardware acceleration in your animations 0% and 100% or in the .link class etc... on the iOS device?
Read more from another answer to a similar problem:
- https://stackoverflow.com/a/10170170/1380685
.link{
-webkit-animation: WIGGLE 1ms;
animation: WIGGLE 1ms;
-webkit-transform-style: preserve-3d;
-webkit-transform: translate3d(0,0,0);
}
The solution came with giving "position:relative;
z-index:1000;display:block" css properties to the whole container that
holds the scroll element and there is no need to give translate3d to
child elements.
Reference URL's
http://en.kuma-de.com/blog/2011-12-26/494
http://indiegamr.com/ios6-html-hardware-acceleration-changes-and-how-to-fix-them/
http://cantina.co/thought_leadership/ios-5-native-scrolling-grins-and-gothcas/
It looks to be a problem others are having though:
http://en.kuma-de.com/blog/2011-12-26/494
-webkit-animation stops when scrolling on mobile safari
If you can get away with it you can use an old-school technique below to have animation persist with less resource intensive operations
You could always use the Base64 encoded asset technique within your initial loaded CSS file.
I recently posted to another question recently asking something kind of related. This way the animation is continuous and preloaded and cached for easy and fast recall via css. Also you can use SVG, PNF, JPG and many other image formats for scaling and re-sizing.
Please read the information posted on the link below to red more about this.
https://stackoverflow.com/a/25224086/1380685
https://developer.apple.com/library/safari/documentation/internetweb/conceptual/safarivisualeffectsprogguide/Using2Dand3DTransforms/Using2Dand3DTransforms.html
A little background: I'm working on an iOS app that has a variety of status icons for various states. These icons are used in a variety of places and sizes including as UITableViewCell imageViews, as custom MKMapAnnotations and a few other spots. I actually have a couple sets which include a more static status icon as well as ones that have dynamic text injected into the design.
So at first I went the conventional route of using static raster assets, but because the sizes were dynamic this wasn't always the best solution and I wasn't thrilled with the quality of the scaling using CGAffineTransforms. So instead I changed gears a bit and tried something else:
Created a custom UIView subclass for each high level class of icon. It takes as input the model object that derives the status from (I suppose I could have also just used an enum and loaded this into some kind of model constructor but this is how I did it) so it can decide what it needs to draw, then does the necessary drawing in drawRect. Since all of the drawing is based on the view bounds it scales to any reasonable dimensions.
Created a Category which has class method constructors that take the model inputs as well as the size you want to use and constructs the custom views.
Since I also wanted the option to have rasterized versions of these icons to plug into certain places (such as a UITableViewCell imageView) I also created constructors that build the view and return a UIImage using the fast iOS7 snapshotting functions.
So what does this give me? Well here's the pros/cons that I can see.
Pros
Completely scalable graphics that can easily be used in a variety of different scenarios and contexts.
Easy compatibility with adding dynamic info to the graphics such as text. Because I have the exact shape data on everything I'm drawing I don't need to guesstimate on the bounds for a text box since I know how everything is laid out.
Compatibility with situations where I might want a rasterized asset but I still get all the advantages of the dynamic view since I'm not rasterizing it till I need it.
Reduces the size of the application since I don't need to include raster assets.
Cons
The workflow for creating the draw code in the first place isn't ideal. For simple stuff I can do it straight in code but for more complex things I'll need to create the vector asset in Illustrator or Sketch then bring it into PaintCode and clean up the generated draw code into something more streamlined. This is not the most ideal process.
So the question is: does anyone have any better suggestions for how to deal with this sort of situation? I haven't found an enormous amount of material on techniques for this sort of thing and I'm wondering if I'm missing a better way of handling this or if there are any hidden gotchas here...performance doesn't seem to be an issue from my testing with my approach but I haven't tested it on the iPad3 or iPhone 4 yet so there could still be some unknowns.
You could try SVGKit, which draws SVG files, and can export to a UIImage, if desired.
I am using the most excellent PHP library ePub to on-the-fly create digital books from HTML stored in my database.
As these are part of a collection, I am including a cover image for every book. Everything works fine in the code but depending upon the device/software interpreting the ePub, the image may get cut off. I have seen 600x800 pixels as a recommended size, but it still cuts it off (for example in Aldiko in Android). Is there a standard size that is recommended in the documentation?
Honestly, I would love a good and readable recommendation for documentation of the ePub format.
So, it seems that Aldiko has the problem, and not the other e-Readers I have tested (Calibre, Overdrive).
After trying various ratios, I found that Aldiko only respects the height:100% style I have called out in the height direction. It doesn't scale the image, only sets the height at 100% of the screen width. I am going to have to go with this being a bug in Aldiko, and keep the recommended 600x800 ratio for maximum resolution.
Another interesting thing I discovered as well; the Aldiko reader didn't recover as well from non-standard HTML. On one of the database entries, a <style> tag inside the <body> disappeared, but the style text did not. This is not the same for the other e-Readers.
The best general advice I found on the internet is Preparing Images for Ebooks Project (PIFEP).
I'm trying to figure out what UI element would be the least significant in lowering the performance of an application when all I'm setting will be either the background color or an image. I won't need any user interaction from the element. I only need the content of the element to show on the screen.
From what I've learned so far, CALayers are very light and I'm comfortable using them, but are they the lightest UI element I can use for simple display use cases?
Thanks!
Essentially, I found that CALayers are the lightest for getting the job done in terms of performance, but UIView isn't much heavier at all, but it has a lot more functionality to it.
As for UIImageViews, they are much heavier, but they have a lot of built in methods to make image manipulation easy.
I hope this can help someone!
In CSS Sprites you will often find padding between each image. I believe the idea is so that if the page is resized then one image won't bleed into another.
I think this depends on the different types of browser zoom (best explained by Jeff).
However, I haven't been able to see this behaviour in my tests. Is this only a problem with older browsers? (I havent been able to test with IE6 at the current time so I'm counting that as 'old').
Should I still worry about leaving space? Its kind of a pain.
For instance :
A CSS Sprite I found for AOL has
padding between each image : VIEW
but The Daily Show decided not to
bother : VIEW
It shouldn't need to be padded, but when zoomed, especially in IE8 (betas more than the RC), there is image bleeding if there is no padding.
Best example is to go to Google.com -> Search, and zoom... you'll start to see "underlines" at the bottom right of the image as the zooming rounds up/down.
In theory, a 1px padding on all sides of a sprite should be fine.
Here's the sprite from Google (images)...
But when zoomed, the +,-,x icons bleed into the main Google logo.
Basically the answer is yes. Two years to the day after I asked this question will see the release of IE9. IE9 has this problem just as much - if not more than any other browser...
It's pretty infuriating because it's such a simple thing to fix.
With iPads increasing in marketshare - its's pretty essential to at least have a half decent experience with zooming un-uniform amounts.
I am going to have to put a single pixel border around every image to match the background color of the adjacent element (potentially different on each side). Fortunately I auto-generate all my csssprites based on an .xml file - so I can do this programatically without too much hastle. It's still a huge pain though...
Simon - My experience is that this is certainly still a problem.
In response to your second question, why not use transparent padding? (Perhaps you are still supporting ie6 and this is non-trivial, in which case, I'm really sorry).
Speaking of the older browsers (those using text zoom), you don't always need padding.
The main difference between your two examples is that the Daily Show sprite already includes the menu item's text in the image itself.
When using text zoom, the AOL menu items could stretch out vertically due to the larger font size, and the menu text might even wrap to two lines. To accommodate for such eventualities, those icons need a little padding to ensure they don't bleed. Typically, you'd just try to make sure it doesn't bleed on any of IE6's five text sizes.
Since The Daily Show's menu doesn't contain any (visible) HTML text its size won't be affected by text zoom (though you might need a line-height: 0; or so to be sure), so it doesn't need any padding.
As scunliffe already showed, browsers using page zoom may need sprites to have a little padding due to rounding errors.