I've attempted several different css animations to move a large image up and down on the screen while I have music playing. I haven't found any variation on speed, distance translated, etc that results in a smooth transition.
I'm developing a chromecast application where I have a very large, absolute-positioned DIV that I'm animating on and off of the screen. It has a pretty complicated layout in it with html, css and images, even animated GIFs. However, as long as I make sure there are no reflows while the animation is performing, I've gotten good performance by using transform: translate() CSS to control it's position. Previously, I was modifying the top CSS property, but the performance was pitiful.
For an example to illustrate, here's some HTML:
<body>
<div>
... Main content ...
</div>
<div id="overlay">
... Overlay content here ...
</div>
</body>
And the corresponding CSS:
#overlay {
position: absolute;
top: 25px;
left: 50px;
width: 1180px;
height: 670px;
transition: all 1s;
transform: rotate(-2deg) translateY(750px);
}
#overlay.active {
transform: rotate(-2deg) translateY(0);
}
With this, all I do in my javascript is toggle the active class on and off to cause the overlay to show and hide itself. I can't get the timeline debugger to work with the remote chromecast, so I don't know exactly what the FPS is, but it objectively feels like at least 30fps. It definitely seems smooth. I hope that helps.
If you look at the Events in the Timeline panel of the Chromecast Chrome debugger, what you'll find is that any Paint to a reasonable amount of the screen takes about 100ms. Yes, 1/10 of a second! This makes any kind of animation (CSS, JQuery, etc.) very tricky and often jumpy.
For the movement of elements, I haven't seen any difference in CSS animation performance vs. JQuery animation() performance. I expect because the awful Paint times hide any differences.
One would have thought that Google would have used some of that great video hardware to improve the Chromecast browser paint performance, but this type of Chromecast app does not appear to be one of their uses cases.
Remember that a Chromecast device
has limited resources (both CPU and memory)
has a stripped-down version of chrome
As a result, you won't be able to do many fancy transitions/translations that you are otherwise able to do on a desktop or the performance (how smooth it is) is not going to be what you would like it to be, more so if you are playing a media concurrently.
Related
I have a webpage with different images of different proportions. I want to display in the best format for different devices: desktop, tablet, smartphone, etc.
Is it best to use CSS3 #media (mx-width: ** px ) or jQuery $( window ).resize(function() and $( document ).ready(function() { with a change in the size of the image?
The last step works very well and does not require to set a lot of different media sizes as in the case of CSS3, but if Javascript is disabled it will not work.
Basically, I want the images to be responsive, but not with re-scaling of the screen of the device, which is what I get with the Javascript code, but offering the full width of the container div when the page and images are displayed in a smartphone. I think that the approach would involve PHP code to get the Client data ( $_SERVER['USER_AGENT'] ) because don't want images to be too big to go outside the screen, and when using a smartphone I don't want the images to be too small to be seen, and here I have the problem of screen resolutio: the pixels of the image can be 1200 px, but it is shown very small because of screen pixel density or resolution.
The best approach these days is using a technique called "responsive image sizes" along with good old CSS to handle image scaling on devices with similar screen sizes.
Using 'resize' event to manipulate the DOM with jQuery is a staging way to bad performance and bad user experience.
The core idea is to load smaller images on smaller screens and down-scale them in browser if image is bigger than required, using:
img {
display: block;
/* You should never upscale raster images in browser */
max-width: 100%;
height: auto;
}
Here is a good article, that covers the concept in details: Responsive Images in Practice
I would recommend checking out lazysizes, it implements lazy-loading as a bonus.
This is how you use it in your markup:
<img
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w" class="lazyload" />
I've been trying to find/prevent why my page is freezing at Firefox, I'm using Chrome's Developer Timeline to track the layouts and paints (freezing doesn't occur at Chrome, a huge issue at Firefox with ~300 UI tiles on the page)
It's understandable that gifs cause paints at each frame (a much much larger paint area than the gif itself, unfortunately) - however I don't understand why Chrome reports a "whole document" layout before each frame - since the size of the gif is constant, it should only cause paints in my opinion
I'm guessing these "whole document" layouts are causing firefox to freeze when there are many elements on the document
(I've researched reflows/layouts, repaints in depth, however none of the articles cover gifs, by looking at the timeline, I would say gifs are major resource hogs)
After more careful inspection and testing, I was able to prevent full document layouts by utilizing a gif container div, such as:
<div style="position: absolute; right: 0px; top: 10px; width: 45px; height: 15px; overflow: hidden">
<img src="/gif_url" style="vertical-align: top"/>
</div>
The issue was probably occurring because of the gif's positioning, happens with both float:right and position: absolute, even when the img element has fixed height and width of it's own (might happen with other positioning styles too)
I didn't dive into the issue too deeply to see what triggers the full document layouts and what not, however, it seems like a good idea to wrap every gif with a blocker div to be sure that browsers calculate partial layouts (I'm guessing there might be a combination of styles that might be able to achieve this inline, but I haven't pushed it yet)
- EDIT (after much inspection) -
It turns out the root cause is Bootstrap 2.3.2's default "max-width: 100%" style for img's
Removing that definition seized layouts caused by gifs
If there is going to be even one gif on the page, that style should definitely be removed / cancelled - otherwise at each gif frame the whole document is being laid out by the browser (chrome in this case, possibly others too)
I have a lovely Star Trek Red Alert animation using CSS3. One of my parent elements has a border-radius along with overflow:hidden so that any content is cropped to the shape of the border radius.
This all works fine in Firefox but Webkit browsers leave some child elements hanging outside the cropped area.
Here is my code:
http://jsfiddle.net/doublewombat/EqK6R/embedded/result/
The div with the class name curvedEdges has the border-radius and overflow:hidden. However the blocks left & right of the 'Alert' text hang outside of this radius, even though they are child elements of curvedEdges. Or in plain English, the left and right edges of the animation should be slightly curved (as in Firefox), not dead straight.
So is this a bug in Webkit, or have I got something wrong?
Here it is on YouTube if you don't have a Webkit browser handy...
http://www.youtube.com/watch?v=3vyVy21nWsE
Firstly, what a cool demo!
I had a look around and it seems a problem not on you are having. The second answer to someone else's problem fixed it for me, although this doesn't work for safari. The fix is to use masking:
-webkit-mask-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAA5JREFUeNpiYGBgAAgwAAAEAAGbA+oJAAAAAElFTkSuQmCC);
The accepted answer to that same question has another fix, which I think could really help you out, but I couldn't seem to get the right combination of elements and border-radius.
I'd been trying to do the same, and was using border-radius to mask elements to a circle.
I was able to use masking and a radial gradient to achieve the desired affect in Safari 6.0.3 (with transitions in position and size).
Here's the single line of code I added to the container (masking) element:
-webkit-mask-image: -webkit-radial-gradient(circle, white, black);
I thought I would have to use hard color stops, as follows, to get the hard edge:
-webkit-mask-image: -webkit-radial-gradient(circle, white 100%, black 100%);
However, it works the same without (perhaps someone can enlighten us on why). The clipping is not as smooth as with border-radius, but it beats the heck out of the image unpredictably exceeding the bounds.
You may need to adjust this for use with older versions of Safari/Chrome etc., I haven't tested it on different versions (aka YMMV).
It appears to be a browser issue as reported on: https://code.google.com/p/chromium/issues/detail?id=157218
Basically, when you apply animation to an element, the browser will handle it in the GPU (Graphics Processing Unit) for performance reasons, while the rest is handled by the CPU. That ends up rendering the animation above the mask.
As a workaround you can try adding an imperceptible transform property, that will also trigger GPU handling for the mask element, promoting it to the same level of the animation:
#redAlert .curvedEdge {
-webkit-transform: rotate(0.000001deg);
}
I guess it may vary depending on browser version, but these other values have also been reported to trigger GPU handling: rotate(0), translateZ(0)
It seems like its an issue with the GPU/hardware compositing. transform: translateZ(0); should fix the issue as well. For more information on this, read http://aerotwist.com/blog/on-translate3d-and-layer-creation-hacks/
-webkit-transform: translateZ(0);
transform: translateZ(0);
I have included vendor prefixes but you can remove them if you want.
Seems its a mixed working fix:
.wrap {
-webkit-transform: translateZ(0);
-webkit-mask-image: -webkit-radial-gradient(circle, white 100%, black 100%);
}
http://jsfiddle.net/qWdf6/82/
You could put an absolute positioned div over it with a border-radius and a thick black border, it will block the parts you want too be hidden.
I made a demo for another question about a similar problem in FF3.6: http://jsfiddle.net/vfp3v/15/
border-radius; overflow: hidden, and text is not clipped
Just as a heads up, this fix only worked for me if I applied the mask on a container with border-radius, but no border. Ultimately I ended up with something like this:
<div style="border-radius: 15px; border: 1px solid red;">
<div style="border-radius: 15px; overflow: hidden; -webkit-mask-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAA5JREFUeNpiYGBgAAgwAAAEAAGbA+oJAAAAAElFTkSuQmCC);">
<span style="position: relative; left; -20px;">Some stuff that overflows.</span>
</div>
</div>
With a border on the inner div, the clipping wasn't perfect.
Totally weird.
I found another possible solution to this bug, using CSS3 clip-path, but it only works in recent versions of webkit (it seems to work in Chrome 24, but not Safari 6.0.2). The following will clip a circle around the element:
-webkit-clip-path: circle(50%, 50%, 100%);
Hopefully this will be implemented by more browsers soon! It seems like this feature could have a lot of cool applications. Here's a relevant blog post: http://blog.romanliutikov.com/coding/css-clip-path-landed-in-webkit/.
Please check this:
http://users.telenet.be/prullen/grid.html
This has a normal speed in safari, but the zoom effect is really slow in firefox.
Interestingly, if I add:
.item {
width:100px;
height:100px;
}
it seems to speed up a little (still not completely fluent). But that is not the size my images are at, so it looks messed up:
http://users.telenet.be/prullen/grid2.html
If I set the item width/height to the size of my images, thing slow down again:
.item {
width:160px;
height:160px;
}
http://users.telenet.be/prullen/grid3.html
Any ideas as that what is the reason of this? I'm out of ideas, I've removed/added statements but nothing seems to help. This is tested in different firefox versions up to version 10.
Thanks,
Wesley
To get your animation boosted, you can remove the box-shadow property from #container .item .thumbnail, this property is heavy and slows your animation.
But if you still want the shadow effect, you can try putting it behind as a background and not as a part of the animation.
It should take some change, but removing the box-shadow property from the animated div will make it faster. The "item zoom" div is the one responsible for the animation. By splitting the "zoom" class from the "item" class, and applying the right css properties on each, the animation shall work faster. (I've tried it with firebug)
HTML:
<div class="item">
<div class="zoom">
<div class="thumbnail">
<img src="...">
</div>
</div>
</div>
Position your elements absolutely so they are not part of the normal flow of the document. This will make it so the browser doesn't try to redraw the page every-time an animation plays.
When elements are relatively positioned, they can affect each-other when one is changed, so they all have to be redrawn to make sure that changing one element didn't affect all of them.
I created a demo and absolutely positioned the elements, you can see that the animations are much more efficient.
Here is a demo: http://jsfiddle.net/QLTbU/
I added a box-shadow to a section of a page recently to give it the same shadow border effect that is seen on Mac OS X apps. It looked great, but I noticed that scrolling up and down on the page made it lag. I usually only see this on pages that have annoying background images and tons of images and embedded videos plastered all over (cough MySpace cough). I originally decided to use box-shadow since I figured that it would remove the need to use an image, which would remove any possibility of scroll lag.
I know that CSS3 is still new, but is this the reason for the lag? Is the shadow being software rendered or something? When I apply the box shadow to smaller elements, it doesn't lag at all. I'm just wondering if anyone else has experienced this.
I just tried it on the Stack Overflow front page, on the #content div using Firebug with a setting of:
-moz-box-shadow: 1px 1px 10px;
And I did notice some scroll lag afterwards. I am using Firefox 3.5.
My question is, what are some alternatives to using this attribute if I want to add a Mac OS X style border to a section of my page?
On a side note, does anyone know if it is possible to apply the box shadow only to the top, left, and right sides of the element and not the bottom? I tried 1px -1px 10px but it still shows the shadow on the bottom. If I keep decreasing the second offset, it eventually removes the shadow from the bottom but then the top shadow is now way darker and bigger.
And yes, I have seen the articles on box-shadow at:
CSS3 Info
fredericiana's blog
Your best bet would be to use -moz-border-image instead. That should solve both your issues.
E.g. you could use an image like this,
, combined with CSS like this
-moz-border-image: url(shadow.png) 10 / 10px;
to create your shadow. And since you're using an image, you can leave out the bottom shadow as well, if you want.
You're not going to be able to remove the shadow from the bottom using -moz-box-shadow; it's not called "box shadow" for nothing. It applies a shadow to the entire box. You can't specify a shadow for each side separately like with border, say. The best you could do is fiddle around with the placement, blur and spread of the shadow. But that inevitably leads to a darker shadow on the opposite side.
I get the box shadow lag as well when I try it on Stackoverflow. It affects performance on Safari as well when I try -webkit-box-shadow, though it isn't as noticeable as in Firefox. The performance will hopefully improve in the future, but I presume the shadow will always have some impact since as far as I know it is software rendered.
This has been fixed in webkit as of two days ago. :)
https://bugs.webkit.org/show_bug.cgi?id=22102
You can pick up a chromium nightly to try it out.
I looked in FF3.6 and FF4 and don't see terrible scroll performance there, so it might be addressed there as well.
The issue still persists in Chrome for Android as of the current date. Some box-shadow combos result in a poor scrolling performance. In my case stacking two inset box-shadows (e.g. top / bottom) lead to the described problem. The only solution I can provide is to make the box-shadows less complex and try again...that worked for me. That's unsatisfactory but yeah instead u can also use the border-image solution or remove the affected box-shadow completely. Hope this gets fixed soon, finally. Btw the Android Version of Firefox does not have the problems anymore (for my css3). Moreover the desktop versions of both browsers are not affected in my case.
#shadow {
-moz-border-image: url(img.png) 10 / 10px; #Firefox under v15.0#
-webkit-border-image: url(img.png) 10 / 10px; #Safari, Chrome under v15.0, Android & iOS#
-o-border-image: url(img.png) 10 / 10px; #Opera under v15.0#
border-image: url(img.png) 10 / 10px; #IE v11+, other new Browser#
}
Cross browser version for old and new browser.
Simple img: http://i28.tinypic.com/2njzkt1.png
style :fixed for images too overload perfomance browser