[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: |
Sun, 6 Jul 2008 11:57:06 +0200 |
User-agent: |
KMail/1.9.9 |
Michael Goffioul wrote:
> The idea here is not to have such notifier for all objects and all
> properties, but only for those that are *not*¨part of the rendering
> process. That means only objects/properties related to GUI
> elements. In the current graphics code, this only concerns
> very few properties in figure class.
>
> From what you say above, it seems that you're trying to
> maintain in the GUI thread an object tree that is the image
> of the object tree in octave, and that you would like to have
> notifiers for all objects/properties in order to maintain your
> image tree in sync with octave. This does not fit with the
> current design in the graphics code, where the intention is
> to have a backend to use directly the octave objects
> (hence the required locking mechanism).
Below I'll try to explain how performance can be greatly improved with
notifications, how dividing properties on "gui-related"
and "rendering-related" could harm backend development, and how - using
modern open source technologies - octave could outperform competition.
Let's consider following object tree (matches attached screenshot):
figure
- axes1
* image1
* line1
* text1
- axes2
* line2
On the figure we have two top level axes objects. They don't overlap, so there
is no need for backend to redraw entire figure when some small property
changes. If I type
# set( line2, 'Marker', 'o' );
in octave prompt, effectively implemented backend should repaint only affected
axes (axes2 in this example).
But optimization should go event further: lets do:
# set( text1, 'FontWeight', 'bold');
Re-rendering entire axes could be very expensive, i.e. because of large image
object. Converting large 3-D cdata into RGB pixmap is time-consuming. Good
implementation would convert cdata provided by octave into rendering
system-specific entity (be it Windows DDB, X11 pixmap or OpenGL texture), and
use it for painting as long as cdata and other appropriate properties remains
unchanged.
In this case, changing font weight of text item should force backend only to
repaint part of image directly below changed text, using cached converted
data. This not only reduces area to repaint by factor of 100, but also
re-uses already prepared data.
To achieve this, backend needs to know when property changes, and refresh only
affected part of the tree.
As I understand, you want to divide graphics objects into 'GUI objects'
(figure, uicontrols in future?), and 'rendered objects'. This isn't bad idea
to design backend around this separation. As I understand - this is the way
FLTK backend is designed - it uses FLTK for GUI objects, and glrenderer to
render axes and all its objects.
But I can't understand why backend developers (*ehem* me *ehem*) have to be
forced to use this scheme.
As you noted - I'm using tree of visual objects that mirrors octave's internal
object tree. This isn't in contradict with using octave objects directly.
I use (or: I will use once they become thread-safe) octave objects directly as
property containers, but to draw them, I have to use objects provided by
tookit and graphics library.
FLTK backend will have to use the same scheme once uicontrols arrive. It will
propably have to implement uicontrols using FLTK widgets . The only
difference is in fact that Qt backend goes deeper using Qt's 'Graphics View'
framework ( http://doc.trolltech.com/4.4/graphicsview.html ). This framework
allows for every line, text, image to be represented and painted as separate
object, with smart and partial repaints, optimizations, full user interaction
and all goodies.
So what I am asking for is a simple yet robust notification scheme which would
allow me to keep backend in sync with octave's object tree. This way
Qt-backend could instantly react to property changes, be responsive, and -
eventually - perform better and look better that competition's product.
Just three methods would do the magic:
- property_changed( handle, name )
- object_added( handle )
- object_removed( handle )
They don't collide with 'figure_title_changed' or 'figure_moved' proposed
earlier, but, IMHO, make them superfluous (again the string comparision and
stuff).
Maciek Gajewski
figure.jpg
Description: JPEG image
- [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, 2008/07/05
- 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/07