Re: Handle graphics plotting functions

Sebastien,

I meant to cc the list but I hit the "reply" instead of "reply-all".
I'm cc'ing the list on this one.

Anyway, I am not sure I understand all of your email. I will start by
presenting my ideas and octplot:

handle graphics
===========
I see handle graphics as way for the user to gain total control of the
plot. This allows for tweaking which is so often needed when making a
formal plot (i.e. for a paper/presentation) and for inventing whole
new kinds of graphs and building them using the primitive building
blocks available. Both these features are missing in gnuplot. While
doing it the "handle-graphics" way might not be the best way to do it,
it is the current de-facto standard (==matlab).

OctPlot
======
Octplot is a stand-alone application written in c++. It is based on
the FLTK toolkit which is small and light (as opposed to QT) and
multi-platform. It uses gl2ps to produce hardcopy and FTGL for
on-screen text (mainly needed for rotated text). It communicates with
octave using sockets. Currently it runs under UNIX, OSX and windows,
but using cygwin. I think the main hurdle to mingw porting is the
socket stuff, but I am not sure how hard it will be to port (if at
all).
The octave end consists of a very small oct file which sets-up the
socket and implements the very primitive communication protocol. This
protocol consists of some commands, mainly for creating new objects
(e.g newline,newfigure,...) and the set & get commands.
On top of these sit the "high-level" m-files which, by using the
object creation commands & set/get only implement all the nice bar
graphs etc...
So in a sense you can use octplot easily from within your IDE just as
you can use gnuplot -- just a bunch of m & oct files which control an
external application.


The intent of my original email was to bunch all of these m-files
together. If you have a handle-graphics implementation which is
matlab-compatible, these m-files should work for you.

Now for the "interactive" bit:

On 2/13/06, Sebastien Loisel <[email protected]> wrote:
> I just looked at it. Let me ask some clarifications.
>
> 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
chose to implement it separately. It can reuse a lot of code in c++
though

> Second, the handle graphics objects (hgo) have too many properties, I think
> they are not needed for the back-end, although they are probably essential
> for the middle-end like octplot. For each object type, I need a precise list
> of properties that the C++ needs to draw it correctly. As you'll see, I'm
> designing it so that the communication is mostly one-way.

1. I lost you on the back-end vs. middle-end terminology
2. Almost all properties are needed for "correctly" drawing an object,
except maybe all the callback and Tag and Type which are purely
informational

> Here's a draft of this spec.
>
> =====REALLY IMPORTANT SPEC======
> I'm putting in parentheses things I don't want to implement yet.
>
> axes: range, (style, labels, log-or-linear, etc...)

you'll probably at least want some control over the tick placement and
axis-labels

> (image: let's skip this one for now.)
> (light: let's skip it too.)
> line: X, Y, (Z?), R, G, B, (stipple pattern.) See below for some details.

marker? legend? width? .. I think they are important, but that's just my opinion

> patch: X,Y,(Z?),R,G,B.
> text: X,Y,(Z?),string,(alignment, style, etc...)

angle is important for the y-axis label

> =====END REALLY IMPORTANT SPEC======
>
> Is this sufficient?
>
> For the line I'm thinking of going this way:
>
> [x1 y1 r1 g1 b1  % P1
>  x2 y2 r2 g2 b2  % P2
>  ...
>  xn yn rn gn bn] % Pn
>
> (add a z column for 3d lines). Then the C++ would draw the lines P1P2, P3P4,
> P5P6, ..., with smooth shading. If you want a continuous curve, you just set
> P2=P3, P4=P5, etc... The patch would be similar (triangles would be P1P2P3,
> P4P5P6, P7P8P9, ...) If there's a performance problem later for solid
> colored lines or continuous curves, I can special case them out later.

If this the internal representation It looks nice. If this is what the
user sees than you just lost matlab compatibility. Matlba
compatibility is not sacred, but you should be aware it is not like
this in matlab.

> When the plot needs to be updated (if drawnow is called, or if doublebuffer
> is off and the prompt comes back) then drawnow (a .m function) will go
> through its internal list of plots and turn each one into a cell array A.
>
> A{1}='axes'
> A{2}=(encode axes parameters)
> A{3}='line'
> A{4}=[P1;P2;...;Pn]
> ...
>
> Then, for each figure, drawnow calls the function internal_my_plot, which is
> a C++ function in an oct file, and passes the id of the plot window (an
> integer) and A. The plot window's previous content (if any) is entirely
> destroyed and replaced by A. If the window didn't previously exist, it is
> created.

Sounds like a good scheme to get things going.

Shai