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

[Michael Goffioul]

On Fri, Jul 4, 2008 at 10:55 PM, Maciek Gajewski
<address@hidden> wrote:
> So, do you want to have notifier method for each property? That would require
> backend author to re-implement a whole lot of methods, most of which would be
> almost identical.

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
}

which is as easy as adding another "else if" part to an existing if
statement.

> String comparisons are cheap these days. I could event bet, that entire
> processor time used for these comparisons, on all octave instances, all
> around the world, would be shorter that time spent by programmers to code and
> maintain all these methods :)

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 :-)

> At the other side - it could be good to have sepearate notifiers per object
> class:
>
> void figure_property_changed( graphics_handle fh,  std::string prop_name );
> void axes_property_changed( graphics_handle ah,  std::string prop_name );
> void axes_item_property_changed( graphics_handle ih,  std::string prop_name );
> void uiobject_property_changed( graphics_handle uh,  std::string prop_name );

That's indeed a minimum. And I almost started to implement that idea.
But I found out that the coding overhead with specific notifiers could be
largely reduced with some preprocessor statements and that a more
generic approach as above was as complex as using specific
notifiers, but with additional (avoidable) string comparisons.

Anyway, the original question was whether the backend should be
notified immediately on all property change, or everything should be
delayed until the next drawnow. From the first reactions, it seems that
early notification of the backend (in whatever form) is preferred.

Michael.