On 07/05/2017 08:25 PM, Thiago Macieira wrote:
On quarta-feira, 5 de julho de 2017 15:31:28 PDT Phil Bouchard wrote:
For example in HTML we could have 1 root_ptr for each HTML page and when
this page is destroyed then the root_ptr guarantees all associated nodes
will be destructed as well.  When I refer to a node I mean the
representation of an atomic variable or a function in Javascript which
is pointed to by a reference counted pointer.  So you can have all the
mess you want in Javascript, when the page is destroyed then all memory
associated to that page is freed.

It's the same thing with QML and its windows.  When a window is
destroyed then all associated variables will vanish as well, cyclic or
not.  From my experience, the only way a window can return a value is
either by sending a signal with its parameters passed by value or by
storing them in some local database.  But the parent shouldn't have any
pointer connection of QML / Javascript type with its child window
(downstream) otherwise it's bad programming.  Ex.:

What's the advantage compared to the current model where the GC runs
periodically and frees unused objects before the window is closed?

- Well with root_ptr the behavior is 100% predictable thus you won't have these rendering lags at random times. It happened to me before when I had relatively complex listitems using shadows and a nested list of pictures for each item; the scrolling speed wasn't constant and I think that's a good way to measure this problem. With root_ptr the complexity will remain linear O(n).

- The code of Qt will be much simpler.

- You won't need a separate thread reserved for the garbage collector if that is already the case.

- The objects are destroyed is the exact reverse order they were constructed thus this will help debugging.


-Phil

_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to