The Squish team is happy to announce the release of Squish GUI Tester version 7.1.1 and 6.7.3, the software quality assurance tool for cross-platform GUI application test automation.
Squish GUI Tester 7.1.1
The first maintenance release in 7.1 series keeps pace with recently released versions of popular GUI toolkits and comes with the support for:
- Squish for Qt: Qt 6.5 LTS
-
Squish for Java: Java 19
We also fixed more than 100 bugs and added other improvements to all Squish editions and source packages. For a detailed list of changes please see 7.1.1 release notes.
Squish GUI Tester 6.7.3
As the last maintenance release in 6.7 series, Squish GUI Tester 6.7.3 does not introduce any new features, but contains more than 35 bug fixes and other improvements in all Squish editions and source packages.
For a detailed list of changes please see 6.7.3 release notes .
Download and Free Trial
Customers and current evaluators can download Squish GUI Tester 7.1.1 and Squish GUI Tester 6.7.3 packages from the Qt Customer Portal. New evaluators are welcome to try Squish out for free with a fully-supported and fully-functional trial of any Squish edition.
Important: Effective March 7th 2023, legacy froglogic customer portal and download area are no longer in operation. New releases of Squish, Test Center, and Coco are available in the Qt Customer Portal instead. Read our blog post about the changes to customer service and customer accounts to get a better understanding of how this may impact you.
it is very nice that Qt is considering accelerating for web.
What lacks now is an acceleration for a full multimedia components.
I mean that QGraphicsScene should accept videos as elements (QGraphicsItem).
This way, Qt will advance WPF from Microsoft in these aspects.
But anyway, dealing with videos means dealing with codecs and their respective related patents and copyrights.
This is great.
Do you have any numbers of the improvement?
How does that affect the memory consumption? Does a transformation on big layer (let's say the <body> tag) involve caching a pixmap of the complete layer in memory?</body>
Benjamin:
The numbers for improvement would change per animation. Like I said, for the leaves demo I see the FPS improving by x4 on raster engine.
Re. memory consumption - this is all QGraphicsView cache, which relies on QPixmapCache, which can be tweaked by QPixmapCache::setCacheLimit(...). btw this is true not just for Webkit, but also for graphics-view based UIs that involve complex elements that have to be animated: The QPixmapCache::setCacheLimit(...) function would tweak the balance between RAM usage and paint performance. But yes, without caching that big layer as a pixmap - paint performance degrades because webkit has to re-render it for each frame.
Note that the leaves demo is rather unusual: the animation is running continuously. The normal use-case for CSS animations is animated transitions between states, which would clean up the layer and thus the image cache after it's done.
Some more numbers using n900 with raster engine: (FPS without accel -> FPS with accel, higher is better)
Translate animation on an HTML table: 10 -> 60
Rotate animation on an element with border-shadow: 7 -> 14
Opacity animation on inline text: 2 -> 18
Scale animation on a medium-size transparent image: 17 -> 24
Scale animation on a large image: 11 -> 18
So acceleration has the potential to give us x2 acceleration for rotation of painted elements, x1.5 for images, x6 for simple HTML elements and x10 for inline text.
Looking good, though I had trouble building the head revision..?
../../../WebCore/platform/graphics/qt/GraphicsLayerQt.cpp:690: error: explicit template specialization cannot have a storage class
../../../WebCore/platform/graphics/qt/GraphicsLayerQt.cpp:700: error: explicit template specialization cannot have a storage class
Sounds interesting project. Can you share a video of that demo running on N900?
@zchydem: to your request, I uploaded a short video:
http://labs.qt.nokia.com/bl...
This runs at about 9 FPS, compared to 2 FPS without compositing. (still not enough, of course).
@Nick: please try again, I think my new commit should fix it. If it doesn't, please let me know which platform/environment you use so I can try to reproduce the problem...
No'am: That commit did the trick =)
The 9FPS on the N900 is not surprising. The CPU usage for that leaves demo is quite high - on this modern Quad Core desktop computer.
The best result I saw was with -graphics-system opengl, and even that seemed too high to expect smooth playback on a small device.
Still, a very good step up. Excellent work =)
@Nick: the leaves fall rather smoothly on the iphone that I'm posting from =)
@No'am
You should try the demo without compositing with the Qt-maemo branch, usually that doubles the FPS.
@aidan
Don't forget the iPhones have a low-resolution screen (153600 pixels against 384000 for a N900).
Great work. Could these changes work in WinCE devices?