[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] octave-to-backend notification of property change
From: |
Maciek Gajewski |
Subject: |
Re: [RFC] octave-to-backend notification of property change |
Date: |
Sat, 5 Jul 2008 15:50:23 +0200 |
User-agent: |
KMail/1.9.9 |
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
- [RFC] octave-to-backend notification of property change, Michael Goffioul, 2008/07/04
- Re: [RFC] octave-to-backend notification of property change, David Bateman, 2008/07/04
- Re: [RFC] octave-to-backend notification of property change, Maciek Gajewski, 2008/07/04
- Re: [RFC] octave-to-backend notification of property change, Michael Goffioul, 2008/07/04
- Re: [RFC] octave-to-backend notification of property change, Maciek Gajewski, 2008/07/04
- Re: [RFC] octave-to-backend notification of property change, Michael Goffioul, 2008/07/05
- Re: [RFC] octave-to-backend notification of property change,
Maciek Gajewski <=
- Re: [RFC] octave-to-backend notification of property change, Michael Goffioul, 2008/07/05
- Re: [RFC] octave-to-backend notification of property change, Maciek Gajewski, 2008/07/06
- Re: [RFC] octave-to-backend notification of property change, Michael Goffioul, 2008/07/07