Gunlaug Sørtun wrote: > Alan Gresley wrote: > >> You are correct there Georg but it's when each dimension is squared >> that the slow down is noticed. The present image (bg.gif) is 4px by >> 4px. This could be fixed with an image of 4px in width and either >> 8px, 12px or 16px in height. >> >> It all about mathematics. :-) > > Sure. I prefer to test though, and have gone through all relevant > browsers' rendering and re-rendering time for tiling and scrolling, for > years. Shape matters - especially in some browsers, but increased > image-size and reduced number of repetitions affect speed the most in IE > and Fx. > > FWIW: latest observations for "smooth scrolling" on one fast and one > slow win-machine, are that Opera 9.26 scrolls only twice as fast as Fx2 > and a bit faster than Fx3b when fed complex backgrounds - in most cases. > Opera 9.5b seems to be almost unaffected by what background it's fed, > and scrolls very fast. > > I like to know how browsers handle these factors on regular web pages, > so I can optimize my own designs across the board. > > regards > Georg
OK I have the test results for just IE7 and IE8 with just a transparent png using this page. http://css-class.com/test/bugs/ie/renderingbands-2by2.htm I first tested just squares. The results below show FF (Gecko 1.8-1.9), Opera (Opera 9.26-9.5) and Safari. 1x1 FF:18%-11% Op:18%-10% Saf:10% 2x2 FF:18%-11% Op:18%-10% Saf:9% 3x3 FF:18%-14% Op:18%-10% Saf:7% 4x4 FF:18%-14% Op:18%-10% Saf:7% 5x5 FF:18%-14% Op:18%-10% Saf:10% 6x6 FF:19%-11% Op:18%-10% Saf:8% 7x7 FF:16%-15% Op:18%-10% Saf:10% 8x8 FF:19%-11% Op:18%-10% Saf:10% 9x9 FF:18%-13% Op:18%-10% Saf:10% 10x10 FF:13%-13% Op:7%-16% Saf:11% The percentage given is what my CPU usage showed on refresh. I have a 1.6gb CPU and 504mb of RAM. Gecko 1.8 shows an after spike. I would see 18% the a split second later 12%. Testing in IE7 and IE8 was different. Since it when of the Richter scale. Off-line the repeated background floods down the page before the content snaps in. Below is the results with the same size images seen above. The seconds indicate how long the flood took to complete. In this time the CPU would show roughly 8% usage. Once the flood was finished the the CPU usage would hit the roof. The star * indicates the safe sizes. 1x1 14% 1/8 second * 2x2 100% 4 seconds 3x3 100% 1 1/2 second 4x4 50%~70% 1 second 5x5 45%~50% 3/4 second 6x6 35%~45% 1/2 second 7x7 28%~32% 1/3 second 8x8 24%~27% 1/4 second 9x9 21%~25% 1/4 second 10x10 19%~22% 1/5 second * Now with non squaring. 4x8 30%~40% 1/4 second 3x8 30%~60% 1/2 second 2x8 40%-75% 3/4 second 1x8 100% 1 1/4 seconds 3x4 65%~80% 1 second 2x4 100% 2 seconds 1x4 100% 3 seconds 2x3 100% 1 1/2 seconds 1x3 100% 3 1/2 seconds 1x2 100% 5 seconds It you map all these results to a timetable it is very clear what is happening. <http://css-class.com/test/bugs/ie/renderingbands-image-size.htm> Well that's some progress made with PNGs at least. Alan http://css-class.com/test/ ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
