On 12/29/2016 04:14 AM, Simon Hausmann wrote:
Hi,
Sorry for the delay...
First I would like to point out this popular Javascript test runs 1.5
faster using Qt over WebKit:
- ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit):
http://www.themaninblue.com/experiment/AnimationBenchmark/html/
- ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler):
http://finitetheory.com/personal/phil/JSBenchmark.tar.gz
- I am still waiting for the QtQuickCompiler request to be fulfilled but
anybody who has it already is welcome to try it out and please let us
know the results.
Anyway good job Qt, that's a good start!
I don't doubt that root_ptr can be used at all. What I'm curious about
is what your thoughts are on how it could perform, how you would map its
strengths to the allocation patterns of QML binding evaluations and
general ECMAScript code.
I am guessing you are referring to QML property bindings here which can
easily be cyclic. So these properties will easily be detected by the
destructor of root_ptr:
https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/root_ptr.hpp#L426
The idea is to keep one root_ptr per container (or instantiation of an
object with a list of children) and each property of this object is
guaranteed to be deleted when the object is destroyed. So that's the
main strength and the same goes for entire Javascript pages where its
memory allocations are guaranteed to vanish on destruction.
Moreover the relation root_ptr (parent pointer) -> node_ptr (children
pointer) is fine. There is one drawback in the relation root_ptr ->
root_ptr where no cyclic detection mechanism is in place. I believe it
is possible to add one there but I don't think it is worth the efforts.
Therefore if you have cycles mostly in property bindings then a root_ptr
per object and node_ptrs for its children will be fine. The node_ptrs
can point to other sub objects having a root_ptr each (a child pointer
can point to a parent). The rest of the code written in QML is
structured like a tree as far as I know and no cycles can be present there.
Thus we just need to confirm what I am saying is right; that QML /
Javascript cycles are present only in property bindings.
Thanks and Happy New Year,
-Phil
For the record: Any animation code that _doesn't_ use QML Animators does
indeed run in the same thread as the STW garbage collector and is
therefore subject to its non-deterministic behavior (from the animation
PoV). QML Animators on the other hand are run entirely in the render
thread and are not affected by any pauses in the gui thread, whether it
is caused by long running scripts, the garbage collector or
blocking disk I/O. If with today's release you want to have guaranteed
lag-free animations, then the use of animators over NumberAnimation,
etc. is required. That is why it _is_ possible to run smooth animations
with the scene graph and QML on crazy high resolution displays at
minimal CPU usage.
That said, it is our expressed goal to improve the garbage collector to
interrupt the GUI thread as little as possible, because not everything
can (and should) be solved with animators. Scrolling in a listview,
delegate re-use, property re-bindings, etc. are things that still have
to run in under 16 ms. So without any doubt there is work to do ��
Simon
------------------------------------------------------------------------
*From:* Development
<[email protected]> on behalf of
Phil Bouchard <[email protected]>
*Sent:* Wednesday, December 28, 2016 2:44:24 PM
*To:* [email protected]
*Subject:* Re: [Development] Proposal for "container-oriented
deterministic memory manager"
On 12/28/2016 08:36 AM, Simon Hausmann wrote:
Hi,
building on the suggestion: do you have any thoughts about how your
allocator could be used instead of a garbage collector in an ecmascript
implementation?
I'll have to look into the details of the ECMAScript but root_ptr can
handle neural networks so I'm not sure why it should fail with ECMAScripts.
I won't be able to reply during the day today but I can study specific
cases this week.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
