I've often been told that CSS 3D transforms are hardware accelerated in Mobile Safari which makes me wonder if the implication is that 2D transforms are not? I can think of no reason why they wouldn't be, since they can basically all be implemented as 3D transforms, but I would like to know for sure.
If it turns out that 2D transforms are not hardware accelerated, any insight as to why would be much appreciated.
You're right, CSS 2D transforms aren't hardware accelerated in Mobile Safari, but 3D transforms are. I'm not sure why it's that way, but perhaps they decided it was overkill for most 2D transforms. Using the GPU unnecessarily could adversely affect battery life.
It's very easy to convert a 2D transform to a 3D transform so it isn't much of a problem. One trick is to use translateZ(0) as described here: http://creativejs.com/2011/12/day-2-gpu-accelerate-your-dom-elements/
EDIT
Apple doesn't say anything about it in their documentation, so it is difficult to get an authoritative source. Here is what Dean Jackson from Apple had to say about it (from http://mir.aculo.us/2010/08/05/html5-buzzwords-in-action/):
In essence, any transform that has a 3D operation as one of its functions will trigger hardware compositing, even when the actual transform is 2D, or not doing anything at all (such as translate3d(0,0,0)). Note this is just current behaviour, and could change in the future (which is why we don’t document or encourage it). But it is very helpful in some situations and can significantly improve redraw performance.
Ariya Hidayat from Sencha wrote a post explaining hardware acceleration on mobile browsers: http://www.sencha.com/blog/understanding-hardware-acceleration-on-mobile-browsers/. Here's a snippet from the post:
The best practice of setting the CSS transformation matrix to translate3d or scale3d (even though there is no 3-D involved) comes from the fact that those types of matrix will switch the animated element to have its own layer which will then be composited together with the rest of the web page and other layers. But you should note that creating and compositing layers come with a price, namely memory allocation. It is not wise to blindly composite every little element in the web page for the sake of hardware acceleration, you’ll eat memory.
Here is an article from html5rocks.com that discusses hardware acceleration: http://www.html5rocks.com/en/tutorials/speed/html5/. Here's a snippet from it:
Currently most browsers only use GPU acceleration when they have a strong indication that an HTML element would benefit from it. The strongest indication is that a 3D transformation was applied to it. Now you might not really want to apply a 3D transformation, but still gain the benefits from GPU acceleration - no problem. Simply apply the identity transformation:-webkit-transform: translateZ(0);
Firefox and Internet Explorer already use hardware acceleration for 2D transforms, so I wouldn't be surprised if the WebKit browsers (Chrome, Safari) include it in the near future.
Related
I wonder, if it is more beneficial to use the abilities of QML for animations, or prefer to use animation files (such as GIF oder MNG) for simple, small-scale animations.
Examples for what I call "simple, small-scale animations" are:
turning Hourglasses
those rotating dots, known from video platforms, while loading
flashing alert symbols
those "recharging buttons" known from many RPGs used for special attacks
I don't know much about the internals of Qt, so I am unsure, whether I benefit from hardware acceleration, when programming the animations (e.g. image rotation) or not. And if so, whether this hardware acceleration outperforms the display of pre-calculated animations from GIF and MNG.
Greetings and thanks,
-m-
I wouldn't worry about things like this unless they visibly slow the performance of your application. Some points to consider:
The use cases you mentioned almost always involve only one "busy indicator" being visible at a time.
Both Image and AnimatedImage have the high DPI #*x file look-up.
Both Image and AnimatedImage support caching.
Both Image and AnimatedImage will use the Qt Quick scene graph to display the images (OpenGL textures, which should result in hardware acceleration).
AnimatedImage has to read several images, but won't require rotation.
Rotation of images is pretty cheap, as far as I know.
It's trivial to swap out one with the other, or with something else.
If you're looking for good general performance advice, read the Performance Considerations And Suggestions documentation.
I'm working on a drawing application which requires high levels of accuracy, and I'm wondering which of the major browser platforms (including the HTML Canvas element, and Flash) give the best sub-pixel layout accuracy, both for drawn elements (rectangles in the Canvas or Flash, absolutely positioned DIVs in the browser), and for text.
There are a number of posts related to this, both on this site and others, (see list at bottom), but many are quite old, and none summarises the current situation.
My understanding is that Flash has native support for sub-pixel positioning, using twips to position objects to one twentieth of a pixel, and that when the TextLayoutFramework is used, this accuracy also extends to text. There is at least one report, however, that this doesn't work properly in Chrome. Can anyone confirm this?
My understanding of the situation in the browsers is that Firefox 14+ supports sub-pixel positioning for text and drawn elements, both in page layout and within the Canvas, but I haven't been able to ascertain how accurate this is.
I understand Chrome (as of v21) does not support sub-pixel positioning at all.
I understand IE9 doesn't support sub-pixel positioning, but it appears from the MS blog post linked below that IE10 will.
I don't know if there's any Mac/PC variance in this, and I don't know also if the accuracy of Flash varies between platforms and/or browsers.
I understand a summary question like this may provoke some debate, but I believe this is specific enough for people to provide useful answers, and hope that this thread can be a reference for the state of positioning accuracy up to now.
Some references:
http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx
Sub-pixel rendering in Chrome Canvas
http://johnblackburne.blogspot.co.uk/2011/11/twips.html
http://ejohn.org/blog/sub-pixel-problems-in-css/
Sub Pixel CSS positioning
https://productforums.google.com/forum/?fromgroups=#!topic/chrome/pRt3tiVIkSI
Currently, you can expect the best rounding and sub-pixel support to come from Mozilla with IE as the runner up. IE might end up being more fine tuned, but their release cycles are so long that Mozilla is likely to stay ahead of them.
As far as doing sub-pixel layout, you may be chasing a wisp, because the sub-pixel advantage improves anti-aliasing issues, not screen location accuracy. Your image will never be more accurate than 1 pixel from the true position, regardless of sub-pixel support.
The reason why some browsers don't zoom properly has nothing to do with sub-pixel support, it is because they are not remembering the exact position and rounding correctly. In other words, they are prematurely rounding the position and that causes the image to be mis-aligned.
Short answer:
No. It is NOT possible/documented.
And even if determined experimentally, it is NOT guaranteed to remain the same in future.
Long answer:
At sub-pixel accuracies, there is a lot of variance among Browsers/OS/HW about how the input is captured/rendered. With h/w acceleration being enabled on most modern browsers, there are a large number variations in rendering across different PCs running different browsers on different operating systems. So much so that, it is possible to even identify every unique user by the slightly different variations in the rendered output of a common sample.
Rather than worrying about the discrepancies in the underlying frameworks, How about designing the UI of your drawing application to be independent of those problems. Couple of methods i can think of right now are:
Allow editing the image at zoomed/magnified levels.
Design a snap-to-grid method for elements.
Update:
The "zoom" operation would your custom implementation and NOT a feature of the underlying frameworks. So if you need sub-pixel accuracy to the order of 1/10th of a pixel, one would need to have a 10x_zoom() implemented as part of you web-app which would render the data from
1st pixel --> 10x10pixels at (0,0),
2nd pixel --> 10x10pixels starting from (11,11).
This way one would have a very magnified view of the data, but the framework is blissfully unaware of all this and renders accurate to the onscreen-pixel(which in our case now is 1/10th of the image pixel).
Also an important thing to note that this operation would consume a lot of memory if done for the entire image at once. Hence doing this for ONLY the visible part of the image in a "zoom-window" would be faster and a less memory intensive process.
Once implemented in your drawing web-app the sub-pixel inaccuracies in the frameworks might not turn out to be a problem for the user as he can always switch into these modes and provide accurate input.
I am moving 10,000 small div elements in a css3 experiment from the top of the browser viewport to the bottom. For this test I use 2 different approaches:
With GPU acceleration using translate3D(x, y, z) or translateZ(0)
No GPU acceleration by simply adjusting the top property in css
Using NO hardware-acceleration runs fairly smooth on Google Chrome.
If I enable hardware-acceleration performance becomes a lot worse. It's so bad the boxes aren't even spread out evenly anymore:
With GPU/Hardware acceleration:
Without GPU/Hardware acceleration:
Question
Why is that so? Shouldn't using the GPU improve performance?
Demo application
https://www.timo-ernst.net/misc/hwtest/
Source
https://github.com/valnub/hwtest
My hardware used for test
Apple Macbook Pro 15" 2015 Model
CPU 2,8 GHz Intel Core i7
16 GB RAM
macOS Big Sur 11.2
Update (2014-11-13): Since this question is still attracting attention I'd like to point out that the problem itself still seems to exist although the mentioned stuttering might not be visible anymore in the provided demo on modern hardware. Older devices might still see performance issues.
*Update II (2021-02-17): The problem still persists but you will have to increase the number of boxes being moved in the demo based on the hardware used. I changed the UI of the demo app so you can now adjust the number of boxes moved to create a stuttering animation for your specific hardware. To replicate the issue I recommend to create enough boxes to see stuttering with GPU/hardware acceleration enabled. Then tick off the box and run the test again without acceleration. The animation should be smoother.
I always add :
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
When working with 3d transform. Even "fake" 3D transforms. Experience tells me that these two lines always improve performances, especially on iPad but also on Chrome.
I did test on your exemple and, as far as I can tell, it works.
As for the "why" part of your question... I don't know. 3D transform are a young standard, so implementation is choppy. That's why it's a prefixed property : for beta testing. Someone could fill a bug report or a question and have the team investigate.
Edit per August 19th 2013:
There's regular activity on this answer, and I just lost an hour finding that IE10 also need this.
So don't forget :
backface-visibility: hidden;
perspective: 1000;
The reason animation was slower when you added the null transform hack (translateZ(0)) is that each null 3D transform creates a new layer. When there are too many of these layers, rendering performance suffers because the browser needs to send a lot of textures to the GPU.
The problem was noticed in 2013 on Apple's homepage, which abused the null transform hack. See http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/
The OP also correctly noticed the explanation in their comment:
Moving few big objects is more performant than moving lots of small items when using 3D-acceleration because all the 3D-accelerated layers have to be transferred to the GPU and the way back. So even if the GPU does a good job, the transfer of many objects might be a problem so that using GPU acceleration might not be worth it.
Interesting. I've tried playing with a few options in about:flags, specifically these ones:
GPU compositing on all pages Uses GPU-accelerated compositing on all
pages, not just those that include GPU-accelerated layers.
GPU Accelerated Drawing Enable GPU accelerated drawing of page
contents when compositing is enabled.
GPU Accelerated Canvas 2D Enables higher performance of canvas tags
with a 2D context by rendering using Graphics Processor Unit (GPU)
hardware.
Enabled those, tried it and failed miserably with the tickbox enabled (just like you did). But then I noticed yet another option:
FPS counter Shows a page's actual frame rate, in frames per second,
when hardware acceleration is active.
Given the highlight in the flag description, I'd speculate that hardware acceleration was, in fact, on for me even without the ticked checkbox since I saw the FPS counter with the options above turned on!
TL;DR: hardware acceleration is, in the end, a user preference; forcing it with dummy translateZ(0) will introduce redundant processing overhead giving the appearance of lower performance.
Check chrome://flags in chrome. It says
"When threaded compositing is enabled, accelerated CSS animations run on the compositing thread. However, there may be performance gains running with accelerated CSS animations, even without the compositor thread."
My expericence is that GPUs aren't generally faster for all kind of graphics. For very "basic" graphics they can be slower.
You might have gotten different result if you were rotating an image - that's the kind of thing GPUs are good at
Also consider that translateZ(0) is an operation in 3 dimensions, while changing top or left is a 2 dimensional operation
I saw you two demo， I think I know the reason you confused：
The animation elements Do not use the left or top to change the location, try to use the -webkit-transform;
All child elements need to turn on hardware acceleration such as use translateZ () or translate3D;
FPS measure animation fluency, your demo FPS on average only 20FPS.
Above, only a personal opinion, thank you!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For basic 3d web application i.e. a few cubes, rotation and translation in 3d space - which is better to choose?
CSS 3d seems the easiest, but is not supported on IE9 or on the roadmap for IE10, and offers less control than the other options.
Canvas & WebGL seems way more complicated, but I don't know if they are future proof.
Why are there so many different techniques for 3D? which is better? which is future proof?
The reason there are so many different options for 3D is because the whole thing is still in a state of flux -- 3D in the browser isn't a finished standard, and of the options you listed, the only one that works in all currently available browsers is Canvas.
IE in particular is unlikely to give you much joy -- as you say, 3D isn't even slated for IE10 at this point. Having said that, SVG was added to IE9 quite late in the day, so there's always hope. But the reason it's unlikely is that Microsoft have made a point of only supporting features which have been formally ratified as standards.
Of the technologies you listed, Canvas is by far the best supported, but Canvas isn't a 3D technology; it's a 2D canvas, and if you want to have 3D effects in it, you need to write them yourself, and they won't be hardware accelerated.
I guess the real answer to your question depends on how important the feature is for your site. If it's just eye candy, which users of unsupported browsers could live without, then by all means do it with some 3D CSS. But if you need to make it consistent in all current browsers, then do it with Canvas.
I'd tend to recommend not using WebGL for your case, because it sounds like it would be overkill for what you're doing.
3D CSS is probably the right answer, but use Canvas for now, until the rest of the browsers add support for 3D CSS.
I know this is 2 years old but I figure I'd post this here for future readers.
What to choose depends on what you need.
Do you need a simple 3d shape with no or little animations? Try if you can do it with CSS3, that's the easiest by far. For IE you can probably get a library that offers support.
Do you need some sweet 3d models with nice graphics and that can do all kinds of stuff? Go WebGL, you can't ask for more control AND performance for 3d in browsers.
Do you need 3d shapes that can do all kinds of stuff, but don't need textures and will work everywhere and won't require much performance? Go Canvas.
CSS3 is just for the eye-candy. You can make it rather easily, style it any way you want and is very easily maintainable. Once you want to do more than just eye-candy, put on your gloves because that is gonna reuire some work.
With 2d Canvas you can make 3d stuff. If you're new to it, it will be very annoying and complicated (to name one example; you need to know of matrices), You can pretty much do anything with 2d canvas that you can do with WebGL but some thing will be easier in WebGL (seriously, if going 2d Canvas, don't try to use textures, it's a nightmare). WebGL uses OpenGL which, in a nutshell, means it will always outperform 2d Canvas.
However, WebGL requires the user to have a compatible video card.
I really depends on what you are trying to do. How simple is simple?
3D CSS is far from usable. It's only just made it into firefox. It's buggy in both firefox and chrome. It's not working in FF9 beta on OSX. It's also got issues in Chrome up through at least 16. See http://greggman.com/downloads/examples/intersecting-elements-3d-css.html and compare Safari on OSX to pretty much any other browser.
three.js (https://github.com/mrdoob/three.js/) used to (and maybe still does) provide some simple 3d using canvas.
Otherwise if you want anything interesting go WebGL and pick a library (three.js, SceneJS, etc..)
You've got to make a choice. Use WebGL and give up IE, Use Flash 11, Use Unity3D, use Canvas and get very limited 3d, or don't do 3d.
WebGL is already being used by major sites. CNN is now using WebGL http://www.stinkdigital.com/en/work/ecosphere
Everyone is probably tired of hearing 'it depends', but...it depends!
There's a little "war" going on as to whether it's better to use Canvas or HTML/CSS3, and namely because Canvas is slower than DOM on older machines/devices. Yeap, DOM is way faster in some cases, while canvas is faster on most modern browsers/devices.
WebGL - Best option for both 2D and 3D, but since it is not well enough supported across browsers and devices, you'll have to offer fallback to canvas or DOM whenever necessary.
Canvas - Less suitable for 3D comparing to WebGL, but more suitable for compatibility, community, tools etc
DOM - Faster than most think, if used right, highest support around, but you cannot go too fancy animation/gaming-wise.
Hope this helps
I'm experimenting with CSS transforms and I noticed that embedded videos (like for instances the ones from youtube) don't behave as expected when a CSS transformation is applied to them.
I've tested this in the latest Chrome, Firefox and IE and none of them was able to display transformed videos.
Is this a bug of sort, or are videos not supposed to obey to CSS transformations? Not even using html5 in Chrome solved the issue.
They do of course. I created a few examples on my book's website HTML5 Multimedia: Develop and Design under 'chapter 7'.
Here's a video undergoing a 3d rotation (Chrome and Safari only - hover over it).
It's highly unlikely you can transform video due to the complexity and processing overhead it would introduce. Computers like to display video in nice rectangular areas which can be reserved and passed directly to display hardware.
The same applies to plugins like Flash and Java.
In short, even if you could do this it's unlikely the result would be watchable except on very high end PCs.
It's possible that one day WebGL will allow mapping video into 3D spaces using hardware acceleration but I wouldn't hold my breath waiting for a solution.
BTW, if you video is simple enough you might find converting the video to an animated GIF solves the issue.