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.
Related
I have already read
What is the difference between SVG and HTML5 Canvas?
&&
https://en.wikipedia.org/wiki/Canvas_element#Canvas_versus_Scalable_Vector_Graphics_.28SVG.29
So i am aware of the basic differences, but i was wondering if anyone had encountered any practical difference between the two within the context of ggvis and shiny apart from SVG inability to deal with NA's in the data
The short answer:
SVG would be easier for you, since selection and moving it around is already built in. SVG objects are DOM objects, so they have "click" handlers, etc.
DIVs are okay but clunky and have awful performance loading at large numbers.
Canvas has the best performance hands-down, but you have to implement all concepts of managed state (object selection, etc) yourself, or use a library.
The long answer:
HTML5 Canvas is simply a drawing surface for a bit-map. You set up to draw (Say with a color and line thickness), draw that thing, and then the Canvas has no knowledge of that thing: It doesn't know where it is or what it is that you've just drawn, it's just pixels. If you want to draw rectangles and have them move around or be selectable then you have to code all of that from scratch, including the code to remember that you drew them.
SVG on the other hand must maintain references to each object that it renders. Every SVG/VML element you create is a real element in the DOM. By default this allows you to keep much better track of the elements you create and makes dealing with things like mouse events easier by default, but it slows down significantly when there are a large number of objects
Those SVG DOM references mean that some of the footwork of dealing with the things you draw is done for you. And SVG is faster when rendering really large objects, but slower when rendering many objects.
A game would probably be faster in Canvas. A huge map program would probably be faster in SVG. If you do want to use Canvas, I have some tutorials on getting movable objects up and running here.
Canvas would be better for faster things and heavy bitmap manipulation (like animation), but will take more code if you want lots of interactivity.
I've run a bunch of numbers on HTML DIV-made drawing versus Canvas-made drawing. I could make a huge post about the benefits of each, but I will give some of the relevant results of my tests to consider for your specific application:
I made Canvas and HTML DIV test pages, both had movable "nodes." Canvas nodes were objects I created and kept track of in Javascript. HTML nodes were movable Divs.
I added 100,000 nodes to each of my two tests. They performed quite differently:
The HTML test tab took forever to load (timed at slightly under 5 minutes, chrome asked to kill the page the first time). Chrome's task manager says that tab is taking up 168MB. It takes up 12-13% CPU time when I am looking at it, 0% when I am not looking.
The Canvas tab loaded in one second and takes up 30MB. It also takes up 13% of CPU time all of the time, regardless of whether or not one is looking at it. (2013 edit: They've mostly fixed that)
Dragging on the HTML page is smoother, which is expected by the design, since the current setup is to redraw EVERYTHING every 30 milliseconds in the Canvas test. There are plenty of optimizations to be had for Canvas for this. (canvas invalidation being the easiest, also clipping regions, selective redrawing, etc.. just depends on how much you feel like implementing)
There is no doubt you could get Canvas to be faster at object manipulation as the divs in that simple test, and of course far faster in the load time. Drawing/loading is faster in Canvas and has far more room for optimizations, too (ie, excluding things that are off-screen is very easy).
Conclusion:
SVG is probably better for applications and apps with few items (less than 1000? Depends really)
Canvas is better for thousands of objects and careful manipulation, but a lot more code (or a library) is needed to get it off the ground.
HTML Divs are clunky and do not scale, making a circle is only possible with rounded corners, making complex shapes is possible but involves hundreds of tiny tiny pixel-wide divs. Madness ensues.
I have past content from the following link.
Please see this link for more details
HTML5 Canvas vs. SVG vs. div
I am using wxWidgets to draw a large flow chart, i.e. 625 x 26329 pixels. The program was transported from Qt to wxWidgets. It is easy in layout with a main frame which has a customized scroll window inside. The scroll window draws part of the chart every time within updated client region.
Now Qt and wxWidgets make much difference. When scrolling vertically with mouse rolling, Qt refreshs painting the chart very smoothly, while wxWidgets is slowly with flicker.
Can anyone tell me how to make the painting efficiently?
Are you sure it's slow? I would be wondering, I encounterd a different experience.
You mention flickering. Flickering is mostly result of too many refresh calls.
To prevent this you must use double buffering and this is the key.
Double buffering means to draw all stuff offscreen into a image / bitmap and after everything is drawn the image/bitmap is drawn fully (this is done really fast so no flickering :)! ).
Qt uses for default double buffering. That's why it looks everytime smooth.
However the downside of this approach is that it consumes performance.
wxWidgets doesn't bound you to that. Instead it says, it's your task to get double buffering.
Also you should look whether you aren't clipping the region you're drawing. Clipping under Windows with wxWidgets gave me a really better performance.
PS:
Yes, old question but I think it's still needed to know how the facts are.
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!
I would just love to ask a question about the possibly of creating a 2D RPG game in Qt QGraphicsView
A game similar to battle heart - http://www.youtube.com/watch?v=0VqlJ_AvFS8
Why am thinking of using Qt?
Qt is cross platform, and the support for mobile platforms like iOS and Android is increasing fast
I want to save the image on HD as SVG
I want to render the images on the fly ( For the example, when the game is loading ) into pixmap images for better performance after scaling them to the appropriate screen size ( So we cab have a ++, better performance, and infite support to any screen size )
What do you guys think about Qt? Do you have any other good options,
Qt make converting SVG to PNGs as easy as it could be, so that's the killing feature why am sticking to Qt
Bests
I've done this, and I can confirm that Qt is a perfectly good option, as long as you're not particularly concerned with download size (you're probably going to end up with a minimum of about 30 megs). You might consider looking into QML for handling your UI animations, as it's particularly well suited for that sort of thing.
I would strongly recommend using the OpenGL 2 backend, as it's fast, and it allows for GLSL shaders, which are good for special effects. It's also possible to use a QGLWidget as the background so you can do direct opengl drawing if needed.
Edit: Source is available at https://github.com/lendrick/Orange-Engine/wiki
I am currently using Flash CS4 to make some sprites. The sprite is completely vector based and should therefore have good quality. However, once I apply some 3D properties to anything, it becomes very aliased. Is there some quality setting I'm missing?
stage.quality = StageQuality.HIGH;
High quality is the default, but if it isn't with you for some reason, that line should and fix it. It might slow it down some though you know. Especially if you have a lot to anti-alias. (There's also a "best" quality which smooths non-static bitmaps if you want to try that.)