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

[Maciek Gajewski]

Michael Goffioul wrote:
> This would indeed mean a lot of small methods, but they wouldn't be almost
> identical: changing figure's position or name, or uicontrol's string lead
> to different actions in the GUI. Moreover, using simple preprocessor magic,
> I could easily reduce the coding effort in the backend to something like
>
> DEFUN_UPDATER(figure, position, ...)
> {
>   // update figure window location

It all depends what are expecting to get.

If you want react only to few events, like: figure resizing, figure title 
change, ui control resizing and label change etc, that's fine.

But it would be really great to have consistent notification mechanism, which 
could replace current 'redraw_figure' completely. I'd love to have interface 
like this:

virtual void property_changed ( handle, name );
virtual void object_created ( handle );
virtual void object_deleted ( handle );

This would allow me to react selectively to all events, without need to 
re-create entire GUI objects tree each time redraw_figure() is called.

In my backend I have separate GUI object for each octave's graphic object. So 
property_changed would act like hub, identifying appropriate GUI object by 
it's handle and sent cross-thread notification to it.

If we have each method called for each property, it would be like over 200 
separate notifiers! And event more after implementing uicontrols.

And in multi-threaded backend they would all do the same: send message to GUI 
thread to update appropriate control.

Just imagine the hell of implementing and then maintaining it: when new 
property is added, all backends had to be updated.

> Even if string comparison is cheap, that's not a reason to waste CPU
> cycles when you can avoid it. What I find stupid in this case is not
> using an information that you have, forcing the backend to find it
> back and wasting CPU time.
>
> > Besides - these notifiers would be used in interactive environments, when
> > performance isn't all that important as in - for example - running large
> > batch calculations.
>
> I don't agree with this. If you consider a resize callback of a figure
> containing some complex GUI with a lot of controls, you can
> end up with updating a lot of things in the GUI. And if these kind
> of things takes 5x longer than in the competition, you can be sure
> people will start complaining :-)

It definitely wouldn't take 5x longer because of few short string comparison. 
All this drawing stuff, talking to window system (whichever window system it 
would be), obtaining resources required for drawing etc. is so much larger 
job that comparing 200 short strings. Besides we are required to compare 
strings anyway when reading radio properties.

And event when string comparison will become problem, efficient hash table 
could fight it easily.

Another idea: create large enum in each property set, containing numerical 
identifiers of all properties. I think this is doable using awk script. Then 
limit using strings only in most top-level user-interacting functions, and 
use numerical id everywhere else.

But honestly I think this is an overkill. I'd stay with string names.

Maciek Gajewski