my current project uses quite a few CSS-based background gradients. They are not used for every element, but they are quite essential for the User Interface.
While integrating them, I was unable to find detailed answers how these gradients affect performance.
Obviously having multiple gradients will use processing power when the respective element is first drawn. Is it known if this gradient generation can also be hardware-accelerated or is this CPU-only?
Additionally, and IMO more importantly, are they being cached? If so, what has to be identical for two elements to share the same "generated" gradient? My first guess would be that the css-statement and the element-size has to be identical (even if the classes that contain this statement are different). It could also be possible that it is being cached by class, but then the element-size could be different and as thus would require another gradient.
For example, if I have a list (ul) with let's say 15 list items (li), which each has a background gradient and includes three elements which also have background gradients, each element type has a constant size. Would the browser generate 15 or 60 gradients?
Pankucins is right - the browser will cache the whole CSS file when it is downloaded. The styles are then rendered when the page has loaded.
Each gradient will be rendered separately; but I really don't think it will be too much of a problem.
Related
I am writing a web app which renders a graph that holds ~700 nodes and their respective edges. Each node is displayed as a circle and inside of it is contained a block of text, a background image, as well as other content. The graph is interactive and the user can both scale and pan the graph. Thus smoothness and high performance is necessary.
Suppose the graph is rendered with SVG. Considering that each node contains rich HTML-like content, it is easier to structure and style the node with HTML/CSS in a div and include it in the graph as a foreignObject. However, with this method there is a noticible performance drop when using the app with mobile devices. Over a modern browser, would you expect a significant performance increase if nodes were structured purely in SVG?
In this particular case, using HTML for each node involves the use of a div with text, and CSS properties like width, height, border, background-image, border-radius, and flex.
Using pure SVG would be more complicated to implement, but would include elements like rect and pattern as well as the corresponding SVG styling attributes.
It really depends on the complexity of the shapes, the size of the graph and how much time you want to put into it. A graph with 700 nodes and thousands of edges sure is a heavy thing. I would advise you to make a small version of the graph (maybe 10-15 nodes) and compare the performance between HTML+SVG and SVG only.
The thing is, using only SVG it is very heavy and not very performatic at all. I guess it'll be very heavy both ways. Have you considered using other tools?
I used this website a while ago to make a flowchart for a website and it worked really well.
Hope it helps.
I'm using Normalizr to display alternate PNG background images, where SVG is being used, for older browsers.
The no-svg class is being triggered, however, there are some strange results: background sizing properties set on the backgrounds are lost on some elements, but seem to be retained on others. Furthermore, I couldn't use shorthand to set this (having to write separate declarations), but I imagine that's the browser's fault.
I need to control the sizing, especially because the layout is responsive.
If you have any ideas, please do reply.
Thank you for your time.
I want to create an opacity blur overlay, similar to Windows Aero or iOS7. Unfortunately the filter: blur() or filter: url(#svgBlur) properties can only apply to the element, not content behind it.
To get round this we need a copy of the background that is blurred. This is possible in FX using the background: -moz-element(#elementId) experimental CSS property. Using that I can get the effect I want in FX only.
There are other questions about solving the blur problem, and one solution appears to be the use of the html2Canvas plug in.
However that is recreating the entire blurred content, including manually recreated styles and the like. It's very impressive work, but it seems like massive overkill (both in performance and size) for this kind of effect.
What I want to do is create is some kind of shim just for -moz-element. It looks like that should be possible using an SVG foreignObject, but that has both security issues and fails if your HTML is not valid XML.
Is there any way round of emulating -moz-element (using canvas, SVG, or something else) where I don't have to parse/redraw the entire overlaid area?
Browsers that support the BackgroundImage pseudo input allow you to filter the content behind an element. Opera 12 supports that and maybe some other UAs too.
I think Opera 12 also supports the SVG 1.2 Tiny feature of having an external foreignObject i.e.
<foreignObject xlink:href="external file url"/>
You could combine this with the backgroundImage to have html content as a background even if the html content was not not valid XML.
Your milage may vary with other UAs though and as you say Firefox has a different solution.
You can check out a plugin I recently made called AeroJS. It does exactly what you're looking for and supports everything but IE.
EDIT: My apologies for not not including a description of the plugin.
Basically, the way AeroJS works is by taking the HTML of a specified element (backgroundElement), the background image of a specified element (backgroundImage) and prepending them to the specified element. Then, using WebKit's blur filter, a specified amount of blur (blurAmount) is applied to the elements in the background. It's still in the early stages of development so bugs are expected. One drawback of using AeroJS is that it's almost entirely static. You can move around the element and everythung behind it will be blurred however any changes that happen to the original DOM will not be reflected in the blurred/copied HTML. Custom code will be needed for that.
If those properties only apply to the selected element, why don't you select them all?
Maybe with:
#myElementID *
So I'm looking at a specific application for a web browser which requires me to express color as a straight alpha channel with a black and white alpha channel as a separate element. (an example of both types
I know many moons ago, IE supported some perverse filter options, but since I'm doing css3 transforms, I need this to work in a modern browser, preferably Chrome.
Basically what I'd like to do is have an element with CSS transforms applied, specifically rotation most likely, then I'd like to take that and copy it to another equivalently sized element which has the black / white transformation applied. An additional bonus would be setting the original element to use straight alpha, but I can live without that for now.
I haven't been able to find any routes with which to start investigating. If you have one, I'd be super grateful. My last resort is to start doing things in WebGL or Canvas and modifying the output there.
Two or three different elements stacked on top of each other using absolute positioning and z-index? This would require you to save two different images which I'm guessing you're trying to avoid.
You can do CSS 3D transforms. Browser support is basically there in newer IE, Chrome, Firefox, iOS and Android.
where can you use them
how to use them
MDN
I've actually figured out the answer... it's CSS Shaders.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
Not yet available, but soon.
The reason not to use Canvas is for simplicity in authoring. (Long story.)
I have recently begun using image sprites and they are definately great for reducing http requests. Is there a point where it becomes bad practice?
Im thinking particularly where a lot of extra markup has to be added to support them. For example, using them for list bullet points, I have to add two or three extra spans to get everything alligned etc.
Theres also the annoying point that you cant use repeating images, so therfore there is always the toss up between one large image as part of sprite or a tiny 1 pixel image used for repeating downloaded on its own.
Im really looking for an opinion on the two situations outlined here + any other general considerations/guidelines for using sprites.
They can often cause performance issues on mobile devices. I'm not 100% certain why (never really dived into the problem), but I'm assuming it's because the mobile webkit is loading a new copy of a relatively large image into memory for every instance of it on the page. Since mobile devices often have very small amounts of RAM, it can quickly cause the page to slow down.
I've run into this issue before when having about 300 "icon" sprites on a page at one time, each pulling from a sprite image that contained about 50 different icons. Going back to "normal" methods of one icon per image (or 2-3 for hover states) solved performance issues on this particular page.
Also, many browsers (mobile and otherwise) will often not 100% respect the clipping of sprites when you slightly resize the page content (e.g. using "Zoom In/Out" on the browser itself). You'll often see little pieces of the sprite next to the one you want to use.
As for your bullet example, you shouldn't ever need more than one extra div/span. You would set a margin-left on the li and position your "bullet div" in the empty space it creates.
That being said, I use sprites all the time because they're convenient, just be aware of a few issues with them. Generally, I have sprites.png, sprites_h.png and sprites_v.png for horizontally and vertically repeating pieces.
Write two simple test pages, use sprites on one, and not on the other. Use a tool like http://www.webpagetest.org/ to measure the performance in a few different browsers. Once you have data, you can make decisions.
I would divide sprites by related elements, like navigation and content-related sprites, so you can benefit from sprites and keep a logical order in your code. Don't forget that readable and understandable code should be a priority (particularly with CSS, it can get very messy) unless you're working on a Google-scale project.