I'm writing first time on this website, because I have big problem with css3 exactly box-shadow, so I start from the beginning :)
I made website and it worked good until I changed all graphic.
I did box-shadow and now my website works very slow (exactly scrolling).
It is address: skuterpl.vot.pl (version with new graphic and box-shadow)
strona.pzs1.pl (Old version with old graphic and without box-shadow, this website works very good).
I'm asking you for help me with this problem.
If you have a very large shadow radius, it can affect performance - there's a post here about it affecting webkit browsers CSS3 box-shadow causes scroll-lag (slow performance) on Safari 5.0.2? , though I believe now fixed.
Lowering the amount of box-radius blur should solve the issue.
things you should take notice of certain factors that can slow down a page:
heavy graphics (like huge backgrounds)
a fixed background
element opacity / image transparency
animated images
text/box shadows
constantly running scripts/event firing (like scrolling events)
although the old page works, i can still see some things that need optimization.
Related
A site I'm working on displays a large number (>50) of complex SVG images in a scrolling dialog window. When viewing the site in Chrome, the scrolling performance of the dialog window is very poor - it is noticeably laggy and slow. However, if I replace the SVG images with PNG images, the scrolling is perfectly smooth and responsive.
Here's a demonstration of the difference: https://jsfiddle.net/NathanFriend/42knwc1s/
Why is the SVG scrolling performance so much worse than the PNG scrolling performance? After the browser renders an SVG image, I would assume it doesn't need to rerender the image until the image is manipulated in some way (like resizing). Does scrolling an element that contains SVG images cause the images to be rerendered for every frame of the scroll animation?
`
I think this is just some kind of a Chromium bug, I've found this issue on SO, because I started experiencing it as well on Mac. It works OK on Opera for instance.
I don't think anyone here will be able to explain why it's slow if it really is a bug. I've created a Chromium bug, please star it if you want the issue to be fixed soon or learn more https://bugs.chromium.org/p/chromium/issues/detail?id=681611
I've spotted some weird behavior across browsers border-radius implementation. Take this code: http://jsfiddle.net/pm7FZ/1/ On Windows every browser excerpt Chrome rounds inner image: http://imgur.com/54In8 Chrome doesn't and the image stays square.
I don't have OS X, but my friend send me this: https://img.skitch.com/20120925-eypjk593tdest3ud9hcji1sauf.png Seems it behaves differently. Although another friend says that if you set border-radius to 20px on OS X it will round the image corners on OS X's version of Firefox.
Question - what is happening here? Why so much inconsistency.
It's obviously easy to "fix", just curiosity.
I can only speculate but here's what I suspect is going on. If you check out the W3C spec for the basic box model (http://www.w3.org/TR/2007/WD-css3-box-20070809/) you'll see a graphic that demonstrates how elements are laid out. Each element has a content area, padding, border, and margin areas. I believe browsers render each of these areas as a layer and where FF would render the 'border layer' on top of the content layer Chrome would render the 'content layer' on top of all the other layers. In your sample if you would remove the height and width attributes from your img tag you'll see the image does get rounded but is not affected by the border itself. I haven't found any specification on the way browsers should handle this but I'm pretty sure the Chrome devs chose this method to squeeze out some more performance.
I have been working on getting this seat mapping chart for a while and have created a few iterations, and the problem I keep finding is when I get to IE8 the panning for this is way to slow and delayed.
What I have at this point to cut down on load time is created a png to replace my "strokes" since I assume ie8 wanted to re-render each time I dragged the map.
I also added controls hoping to force IE8 users this option, but still there is a delay in the pan, and if I can have users with IE8 (and ie7 if possible) still drag/pan without the controls and the respond time a little faster that would be great.
Here is my current JSFiddle
I am still a little green with JS so if you have any suggestions it would be much appreciated. (PS Chrome frame is awesome but is not a option for me)
Update
I have removed the original dragging function and replaced the code using jqueryui's draggable function. Martin had suggested to just drag the div, and not the Raphael elements. Doing so lets this thing fly in ie6-8 which is great, but then came my concern about scaling. What I was seeing before on zoom my paper element WxH would stay the same ratio, cutting off my drawing when it zoomed in. After digging through the Raphael documentation I came across paper.setSize. setSize was exactly what I needed to allow this project to move and groove in ie6-8 and pretty much conquer all browsers in its path.
So in short, using jqueryui's draggable and paper.setSize has cured my cross browser zoom n' pan blues.
From what can be seen in the Fiddle, you are triggering a new rendering of the image by calling .translate() inside of a mousemove event handler:
mapContainer.translate(currentMapPosX, currentMapPosY);
rsrGroupies.translate(currentMapPosX, currentMapPosY);
This approach is toxic for performance in all browsers, let alone IE8. When dealing with VML in IE8 you should consider that each and every DOM change inside the image will result in the image being rendered again. Doing that while panning will always be painfully slow.
I see that you are already using jQuery in your Fiddle. If you want to increase performance of your panning, you should consider doing the following:
Render the image in Raphaël exactly once for the current zoom level. Do not attempt to change transformations in your VML/SVG image at any point in time while panning.
With the mousemove implementation of panning you already have, move or scroll the HTML container that holds your VML/SVG image instead. Imagine a <div> with overflow: hidden and simply move the image inside relatively, or scroll to the appropriate position.
This will require some adjustment of your coordinate calculations, but it will improve your performance in all browsers.
I'm using css animations on my page and Safari seems to change unrelated font weights elsewhere on the page when animations are running. Any idea why this happens? All other browsers work fine, include webkit ones like Chrome.
I've detailed the bug in a video here - http://www.screenr.com/gZN8
The site is also here - http://airport-r7.appspot.com/ but it might keep changing rapidly.
I'm using compass (#transition-property, #transition-duration) on the arrow icons. No transitions applied on the heading that's flashing. On a Mac - so it might be the hardware acceleration, but I'm still trying to figure it out.
When you trigger GPU compositing (eg, through CSS animation), the browser sends that element to the GPU, but also anything that would appear on top of that element if its top/left properties were changed. This includes any position:relative elements that appear after the animating one.
The solution is to give the animating element position:relative and a z-index that puts it above everything else. That way you get your animation but keep the (superior IMO) sub-pixel font rendering on unrelated elements.
Here's a demo of the problem and solution http://www.youtube.com/watch?v=9Woaz-cKPCE&hd=1
Update: Newer versions of Chrome retain sub-pixel antialiasing on GPU composited elements as long as the element has no transparency, eg has a background with no transparent or semi-transparent pixels. Note that things like border-radius introduce semi-transparent pixels.
Apparently, that's the price you pay for hardware acceleration: all text momentarily turns into images, which causes the drop in render quality.
However, applying html {-webkit-font-smoothing: antialiased} to turn off the sub-pixel anti-aliasing makes this problem go away. That's what I'm doing for now.
UPDATE: Since then, I've also come to learn that this happens only when the browser can't be sure if the section being animated is going to affect the text. This can usually be handled by having the text above (higher z-index than) the elements being animated, and/or making sure the text has a fully opaque background.
I've faced this issue numerous times and have had success adding the following css to the animated element:
z-index: 60000;
position: relative;
It seems it needs both z-index and position to be effective. In my case I was using it with Font Awesome animated spinners.
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