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)
Related
I created a set of small PNG files to hug the top and bottom of my website. By repeating themselves on the X-axis they span the entire width of the site and actively shrink and expand with the browser. This worked as predicted until the upper span was pushed to the right allowing another image (logo/button) to occupy the upper-left corner. This repeating image and the banner logo are a contiguous image so I'm doing my best to make it work as designed. I added this bit to my style sheet to nudge the repeating image over to the right:
left:650px;
This caused a horizontal scroll-bar to appear allowing access to a big-open-nothing at the right side of my site (it appears to be the same distance the PNG is being pushed over to). I believe this is called overflow? To constrain the overflow I added the following to the html, body tag in the style sheet:
width: 100%;
overflow-x: hidden;
This removes the scroll-bar in all the browsers I've tested (Chrome, IE, FF & Opera) but in most cases, side scrolling can still be invoked by clicking down on the center mouse button and activating the easy-scroll feature (I don't know the actual name of this feature, but hope you understand what I mean).
FF deactivates this mouse feature but still allows scrolling with the keyboard arrows. IE is the only browser that is working correctly.
I've looked all over for an answer but have only netted some possible solutions, but I don't understand how to implement or even how to describe them. Being a novice I suspect incorrect terminology is also hindering my searches. In any case, if you take a peek at my website:
http://www.cybergolem.com/indexWIP.php
BTW, my div nesting looks like this:
<body>
<div id="container">
<a class="homebutton" href="index.php">Home Page</a>
<div id="header"></div>
</div>
<div id="footer">
<div id="footNote"> — Thar Be Dragons Here — </div>
</div>
</body>
Thanks Much.
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.
Just wondered if anyone using the Flexslider has found that when switching back and forth from different size browser windows the slide images do not automatically adjust to new height and widths.
Let me clarify - they do shrink correctly but when scaling back up the first image in the slideshow gets stuck at the previous aspect ratio until the next slide comes in, at which point the whole thing adjusts.
To stop my content from being affected I have created a fixed height container for the flexslider and have used media queries to change its height as it is scaled down. This works perfectly scaling down.
It seems to be on the way back up that it has trouble sorting the image heights out.
I would provide links but it is a new client project in confidence.
All coding is exactly as is from the demo files, with exception to the fixed height and media queries on the container div.
I had the SAME problem - I found that not all my widths were of the same value.
e.g.
.clone { display: block; float: left; width: 994px!important; }
<img src="http://www.website.com/images/panel1.jpg" alt="" width="980px">
There were about 4 instances in my css that had different widths [shame shame] so I went in there and raked the css file.
I hope this helps
Good Luck
I have quite large text (font size 28) I'm trying to align vertically in a fixed-height container.
I'm doing this by eye and just setting a margin-top so that it gets to the right spot. However, when in Firefox, I need a margin-top of 20px, in Safari I need like 15px (else it's too far down). I saw that the discrepancy was because in Safari the text element is taller than in Firefox and includes a slight amount of whitespace on top that doesn't show up in Firefox (in Firefox, the top of the text element is exactly when the text starts).
I've tried all kinda of display combinations with line-heights and perhaps adding a width/height for the text and whatnot. Nothing works.
What can I do to make this consistent? I'd hate to use JS but it seems like the only option...
For cross-browser CSS normalization I'd recommend a reset - YUI3 has a good one, Twitter Bootstrap is another good one. It basically sets paddings and margins to 0 so all browsers will behave and only adhere to YOUR css rules and not their own default rules.
For vertically aligning text to containers, if it's a single line of text, use the line-height property, and set it to equal the height of the container.
For example:
CSS:
div {
height:300px;
width: 400px;
line-height: 300px;
font-size:28px;
background-color:#F0F0F0;
}
HTML:
<div>
Some vertically centered text
</div>
Example: http://jsfiddle.net/Djvv7/
You need to apply a css reset. Good practice to use one on all projects. The most famous I know of is: http://meyerweb.com/eric/tools/css/reset/
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