Re: [RFC] octave-to-backend notification of property change

[Maciek Gajewski]

I have and idea which is hybrid of both of these solutions:

Let all "set" methods notify backend using the same method, with signature 
like this:

virtual void base_graphics_backend::property_changed( const graphics_handle& 
owner, const std::string& name );

This would be desd simple at part of octave, and allows abckend to choose  how 
to deal with it.

FLTK backend, which lives in octave's main thread, could filter our important 
properties and repaint if needed.

My Qt backend[1], which uses separate thread for GUI, could implement this 
method so it sends cross-thread messages to GUI when important property 
changes.

Additionally, backend couild decide which properties should triger immediate 
reaction, and which can wait to next repaint.

To make things fancier - backend (both single-and multi threaded) could put 
(handle, property) tuple into some sort of queue, and repaint only at some 
sane intervals. This could avoid overheting CPU with frequent redrawing.

Regarding competition: I'm pretty sure that current implementation is 
multi-threaded - so described behavior with moving figure. 'drawnow' is 
possibly just a relic.

[1] Qt backent is very actively developed by me, see: 
http://code.google.com/p/qoplot/

> Hi all,
>
> I'm currently in the process of implementing the mechanism used by
> octave to notify the backend about property changes that can impact
> GUI elements. I'm not talking here about objects contained in an axes
> system, which are handled during the axes rendering, but about
> actual GUI elements. For instance:
> - "name" in figure => change figure window title bar
> - "string" in uicontrol => change control string (for instance the
> text of a button)
>
> When such properties are changed, the backend must be notified
> in order to update its internal GUI elements. I thought about 2
> possible mechanisms:
>
> 1) In the "set" method of the corresponding property (for instance
> in figure::properties::set_name), call a specific method in the
> backend to notify it (for instance update_figure_name). The
> real backend implementation can then overload the method and
> implement the appropriate action.
>
> 2) Delay the backend notification until next "drawnow". This can be
> done by adding a "modified" flag to the property class, which is set
> to "true" when a property is modified. During the next drawnow, the
> real backend can then poll all properties it knows about, check if
> they changed and implement the appropriate action.
>
> Now let's talk about advantages and drawbacks. Option 1 imply
> a lot of methods to add to the backend classes, especially for
> uicontrol objects, but the effort can be largely reduced with some
> preprocessor magic (I experimented it). OTOH the backend becomes
> very responsive, because the it gets notified almost immediately.
> However for functions/scripts that modify a lot of those properties,
> the CPU overhead due to method call and possibly thread
> synchronization can quicly slow things down. At the opposite,
> option 2 does not requires much coding in octave (most of the
> work will be done by the backend), but you'll only see the visual
> result of changing a property in the next drawnow.
>
> I experimented a little in the competition, and used the following
> piece of code
>
> figure;
> for k=1:500, set(gcf, 'position', [k 50 500 500]), end
>
> You can see the figure window moving, which means that something
> similar to option 1 is used. I started to implement option 1, but then
> I started to doubt whether it was the best solution. I tried to figure
> out a use-case where a bahevior like in option 1 would be required,
> but could not find any.
>
> So, does anybody have any comment or scenario that would be
> in favor of one option vs. the other?
>
> Thanks.
> Michael.