octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: integrating QtHandles with Octave


From: Michael Goffioul
Subject: Re: integrating QtHandles with Octave
Date: Thu, 9 Jan 2014 15:06:25 -0500

On Thu, Jan 9, 2014 at 2:34 PM, John W. Eaton <address@hidden> wrote:
I'm working on integrating QtHandles with Octave.  When I have
something ready, I'll be pushing my changes on the gui-release branch.
So far, I have done enough to make it compile and show plots but I've
noticed some problems.

First, doing "rundemos draw" (previously "rundemos plot", but
top-level plotting functions have been moved to the plot/draw
subdirectory) hangs on a number of demos including all those for ez*
plot functions and a few others.  I haven't investigated too much, but
the common thing seems to be the use of function handles.  I also
haven't tried building the QtHandles package for an older version of
Octave.  I can do that, but maybe someone who has that already set up
can just tell me whether the demos for the ez* plot functions work
properly with the QtHandles package and Octave 3.6.4.

Second, I noticed some random crashes.  I guessed that this might be
due to not using --enable-atomic-refcount, so I rebuilt with that
configure option and haven't noticed a crash since.  However, I have
not done extensive testing.  I think Michael said that this is
required for QtHandles.  If so, then we have some decisions to make
because as I recall using the atomic reference counting option had a
significant (about 10%) impact on performance.  If we enable it by
default, it will slow all Octave operations.  If we want to enable it
for the GUI only, then we will have to build a completely separate set
of libraries for octave-cli.

I remember that we discussed this topic previously, but I don't think
we ever came to a conclusion.

Atomic ref-counting is required for QtHandles, as the GUI runs in a separate thread and accesses graphics objects from there. There is indeed a performance penalty, which is more visible when creating/deleting a lot of objects; it doesn't impact pure math routines, like BLAS or LAPACK. No decision was made at the time, as it was believed the performance penalty was too high.

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]