From graphics-request at octave dot org Mon Feb 13 13:41:38 2006 Subject: Re: Handle graphics plotting functions From: Sebastien Loisel To: Shai Ayal Cc: octave-graphics Date: Mon, 13 Feb 2006 13:36:21 -0600 ------=_Part_7701_31776261.1139859284867 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think there's some sort of misunderstanding somewhere. > You need a C++ function to draw the following objects: > > axes, image, light, line, patch, rectangle, surface, text? > > I propose to narrow it down: > > axes, image, light, line, patch, text. > > Octplot already supports line,patch,text,surface (2D),axes,figure > > > rectangle and surface can be implemented on top of patch, no? > > yes, although doing surface in c++ is more optimised which is why I > > 1. I lost you on the back-end vs. middle-end terminology > 2. Almost all properties are needed for "correctly" drawing an object, > Basically, there's a back-end. In a simple world-view, the back-end is OpenGL. However, as you know you can't call OpenGL from .m files. So you ca= n either write OpenGL bindings for Octave, or you can write the minimum you need to write to do HGO. What I want to write is a "minimal OpenGL" so you can do the actual HGO in octave. Because octave is so slow, it's not a good idea to have this back-end at exactly the same level as OpenGL. Instead, the back-end should be slightly better than OpenGL. However, since this octave-OpenGL adapter is written in C++, I just want to make sure it's as simple as heck. The "middle-end" is the thing that takes gold-standard HGO-like structs lik= e Matlab produces, and when "drawnow" is called, calls the back-end and draws everything. The middle end is written all in .m files, and its input is standard Matlab stuff, but its output is black magic that feeds into the back-end. For an example, look at the myplot.m function I have. The input t= o myplot isn't gold-standard like plot(), but it looks a lot like plot(). It takes a n by 2 matrix, interprets it as [x1 y1; ...; xn yn] and then basically does the equivalent of plot(X,Y). However, to do so it calls my black-magic C++ back-end, and it converts this n by 2 matrix into what the back-end needs. Basically, I was hoping to do the entire HGO like the myplot.m file I gave, only the input would be identical to Matlab. I guess the front-end is how you use plot(), line() and so on. Anyway, I guess I'll just muck around and see where it takes me. Cheers, Sebastien Loisel ------=_Part_7701_31776261.1139859284867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think there's some sort of misunderstanding somewhere.

> You need a C++ function to draw the following objects:
> axes, i= mage, light, line, patch, rectangle, surface, text?
> I propose to na= rrow it down:
> axes, image, light, line, patch, text.

Octplot= already supports line,patch,text,surface (2D),axes,figure

> rectangle and surface can be implemented on top of patch, no?<= br>
yes, although doing surface in c++ is more optimised which is why I<= br>
1. I lost you on the back-end vs. middle-end terminology
2. Almos= t all properties are needed for "correctly" drawing an object,

Basically, there's a back-end. In a simple world-view, the back-end is OpenGL. However, as you know you can't call OpenGL from .m files. So you can either write OpenGL bindings for Octave, or you can write the minimum you need to write to do HGO. What I want to write is a "minima= l OpenGL" so you can do the actual HGO in octave.

Because octave is so slow, it's not a good idea to have this back-end at exactly the same level as OpenGL. Instead, the back-end should be slightly better than OpenGL. However, since this octave-OpenGL adapter is written in C++, I just want to make sure it's as simple as heck.

The "middle-end" is the thing that takes gold-standard HGO-like s= tructs like Matlab produces, and when "drawnow" is called, calls the bac= k-end and draws everything. The middle end is written all in .m files, and its input is standard Matlab stuff, but its output is black magic that feeds into the back-end. For an example, look at the myplot.m function I have. The input to myplot isn't gold-standard like plot(), but it looks a lot like plot(). It takes a n by 2 matrix, interprets it as [x1 y1; ...; xn yn] and then basically does the equivalent of plot(X,Y). However, to do so it calls my black-magic C++ back-end, and it converts this n by 2 matrix into what the back-end needs.

Basically, I was hoping to do the entire HGO like the myplot.m file I gave,= only the input would be identical to Matlab.

I guess the front-end is how you use plot(), line() and so on.

Anyway, I guess I'll just muck around and see where it takes me.

Cheers,

Sebastien Loisel



------=_Part_7701_31776261.1139859284867--