Re: Qt-based graphics backend - idea.

[Michael Goffioul]

On Wed, Jul 2, 2008 at 6:43 PM, Maciek Gajewski
<address@hidden> wrote:
> Design:
> 1. create new backend (inherit base_graphics_backend), registered in
> some 'init' function.
> 2. during initialization - create new thread for GUI operation, intitialize Qt
> facilities in this thread.

You should consider 2 situations:
1) there's no GUI thread running and you have to create one
2) there's already a GUI thread running and you should attached your
backend to it

The second situation allows to integrate your backend into another
running aplication.

> 3. In response for backend calls (close_figure, redraw_figure, print), send
> appropriate message to GUI thread, also copy object properties (syncing
> threads), so they can be safely accessed by GUI code from GUI thread.

I used to do something similar in JHandles, but eventually dropped the
idea for efficiency (copying all props takes time) and maintenance
(keeping 2 property sets in sync, property addition...) reasons. The
main problem is then to avoid race conditions. I proposed a locking
scheme a few months ago on this mailing list, but we didn't really
reach an agreement. But I hope that in the future, octave will provide
a mechanism to access graphics object properties in a thread-safe
way, without having to duplicate all properties. For the time being,
the GTK-based backend I use as test (as well as the Java-based one)
access properties directly from the GUI thread.

> 4. Draw everything in GUI thread, using data from copied property tree.
> 5. All callback calls triggered by GUI (i.e. ButtonDownFcn) in GUI thread
> should be queued, and called from main thread in function registered
> with 'input_event_hook'.

That's something that any threaded backend will have to do. So I'm
wondering if it wouldn't be beneficial to have a basic framework to
execute callbacks integrated into octave, instead of having any backend
registering an input_event_hook function to do actually the same thing.

> (step 1, 2 and partially 3 are somehow implemented already)
>
> I'd like to ask You for opinion and ideas - is anyone seeing any major flaw in
> above design?
>
> Also, I'd like to ask about current status of 'uicontrol' implementation. Is
> there any planed? My entire project comes from need of having decent 2D
> plotting, especially using 'image', and basic uicontrols. So if no one is
> working on uicontrols, I'd like to add at least basic ones. I need pointers
> on when to start.

uicontrol support is still in my TODO list. But in order to implement it,
I still need to define a couple of things in the graphics framework,
especially the octave-to-backend property-change notification scheme.
However, if you want to contribute to uicontrol implementation, this would
be very helpful. Something that can be done immediately is to add the
uicontrol class in graphics.h.in, as well as the interface functions to
create uicontrol objects from octave.

Michael.