octave-maintainers
[Top][All Lists]
Advanced

[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



Attachment: figure.jpg
Description: JPEG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]