I just finished designing this splash page for my startup: http://beta.mergenote.com/
Load time and initial render is a snap across all the browsers I've tested. (I haven't looked at any IE versions, but sourced it to friends who all felt it was similar enough to Chrome they didn't notice anything.. they aren't web devs though so if you spot something let me know).
The web page used jQuery for a simple slideshow, and for parallax scrolling it uses skrollr https://github.com/Prinzhorn/skrollr
It uses an SVG sprite, whose width and height have been set to 3x the largest rendered size of any of it's icons (because of an Opera and Firefox rendering issue where SVGs don't get redrawn at their final size).
On Chrome / Safari, the site is smooth, fast, no issues. On Firefox and Opera (and especially Firefox) the page takes a very long time to repaint on either resize or scroll events, and the animations are all extremely choppy.
I suspect it may be the SVG sprite, but I'm really not sure. The problems I'm having may intensified slightly when I sized it larger, but were there before hand.
Any ideas?
For me it's pretty obvious that the SVGs are the issue. I've disabled them one by one and the page is now fast (it was lagging a lot before).
Even if a single SVG comes into the viewport, the page starts lagging immediately.
It uses an SVG sprite, whose width and height have been set to 3x the largest rendered size of any of it's icons
Could you elaborate? This SVG is 2250 by 10350 pixels. It will take a huge amount of RAM to rasterize. It could as well be 225x1035.
Related
I have noticed that when I view a image in a browser using either the zoom provided in the setting or on a webpage using style attributes the pixelation is either negligible or un noticable. But when you use programs such as paint or photoshop or windows picture viewer you start to notice pixelation. Does anyone know how the browser zoom its image contents?
Here is a sample image the one on right is from paint while one on left is when viewing in chrome. The zoom is set at 500%.
For fonts, I believe it has to do with font sizing. Okay, so say you are in a word processor and type something up you increase the font size the text gets bigger. A similar thing happens in a web browser when you zoom in.
On the other hand when you take an image the resolution is set so as you zoom in the the pixels become larger and more noticeable this is called aliasing. Many times a program or browser, etc. will try and smooth the edges in the image to make the pixels look less blocky to the eye, this is called anti-aliasing.
As far as the actual algorithms behind behind paint or a web browser go, I am unsure. It may take some more research to find out.
I have a website with 3 full screen background images that use a custom parallax scrolling script utilizing requestAnimationFrame and transform:translate3d() for its animation. I did this because after a fair amount of research on the subject of visual performance this was the best alternative then using canvas.
My problem is that my page runs very smooth on Firefox 29.1 (*because it is most definitely using the computers GPU to render the page and composite layers) however for some reason, Chrome is has some major bottlenecks.
I am getting tremendous performance spikes (way less then 30fps) when I scroll down my page... but an interesting thing I noticed was that it happens specifically just as one of the background images that is being animated with the script (set as background-position:cover) enters into the viewport.
There is a repaint operation happening because the background image is being resized to fit the viewport width/height and that is causing a tremendous performance hit. Considering that the gpu isnt working correctly for my Chrome, but also that I would like to make my page perform super silky smooth when scrolling even without hardware acceleration, is there a method of preloading images/frames and having them already resized before they are scrolled onto screen? Like a frame buffering technique to ensure all the calculations and resizing is finished well before a user scrolls to that image on screen?
I am experiencing bad rendering of SVG image with Firefox on Ubuntu. You can see on the attached image that the letter J has a little black line below it. This artifact happens only at certain zoom levels. The image is added with the <img> tag, so it is not a background. The image is created with Inkscape. It renders properly on Chrome, I didn't try on other OS.
Is there a way to fix this keeping SVG ?
EDIT: since this affect only the image on the border, I found a workaround opening the SVG in a text editor and increasing the height and the width of a couple of pixels which means leaving a bit of transparent padding around the text.
I am still curious if this is a firefox bug though
In Principle the rendering of SVG is not worse in Firefox than in any other browser. But each browser has its own little lacks in rendering, especially when shapes are close to each other and scaling comes into play.
So I might suggest to review your graphic and give a little room around the letter, so that there is no shape »snapping« directly to the outline of the letter. Unfortunately I cannot see the code of your graphic, but I am pretty sure that the issue is caused by shapes which are very close to each other (arranged by »snapping«) and there is no »saving overlap«.
For Fonts there is Hinting, what optimizes the rendering, especially for small sizes, but for SVG there is no such thing and since you cannot say for sure how each browser will handle those »edge cases« it is up to you to prepare the graphic so that those failures cannot appear.
I'm having some real difficulty with offscreen rendering with HTML5!
The code I have written runs perfectly fine with Firefox, using drawImage on canvas elements draws smooth images and does so very quickly.
However, using Chrome 21, the drawImage performance is just terrible. I'm unable to see where I'm going wrong.
Here is a jsfiddle with some sample code:
http://jsfiddle.net/DXgum/3/
In Firefox, I can get about 60fps, chrome only delivers a framerate of 10fps.
The performance does not differ if I'm using in-dom canvas elements or not-in-dom.
Rendering without buffering on Chrome is faster than Firefox, so I'm actually not sure why Chrome is having such a problem with drawImage.
Any help or light into the matter would be greatly appreciated!
System Information:
Windows 7 32bit
Intel QX9650
Nvidia GTS 250
4GB DDR2 RAM
Chrome Version: 21.0.1180.60 m
Firefox Version: 14.0.1
I've been struggling with this for years. One version of chrome it's fine, the next release it's slow again... My ultimate solution is a little hacky, but it works.
Using your fiddle I was able to determine for sure that performance massively dropped off if the size of the canvas is <= 256.
My canvas was 200 x 200.
I simply made my canvas 258 x 258, change all the math to accommodate the new dimensions and used the CSS zoom property on the canvas's wrapper div to shrink the appearance of the canvas down to the approximate original size.
Doing this, I went from 30-40 fps to a nice steady 60.
By browser rendering performance I mean things like: scrolling, moving elements in animated fashion, z-order changes.
In particular I get tremendous slowdown in Firefox 3.6 and IE8 when I move an image with top, left styles over my page. I have no problems with Chrome 8.
With firebug I tried hiding page elements one by one and the largest improvent by far came from the page wide background Jpeg that I use. I wonder how is it affecting performance as the image is moving above another element that obscures the background. This another element is partly transparent PNG (but not in the part the movement happens), maybe this has something to do with it? I use a lot of transparency and CSS3 effects and somehow they slow down everything, even things that look completely unrelated.
Overall I get the impression that the browser is rerendering the whole page when something is moving, instead of only the affected pixels.
Any educated guess as to why all this happens?
EDIT Any picture or text that sits below my moving image causes it to slow down a lot when passing over it. The moving image itself is with transparent background, but changing it to opaque had almost no effect.
Moving a transparent element (particularly an element with a shadow) over a fixed background forces it to be recomposited every frame. Opaque shadowless elements on the other hand can be moved with a simple blit.
If you want to see a huge slowdown in most browsers, make a page with a bunch of elements with border-radius and box-shadow, then set the background of the page to background-attachment:fixed.