From graphics-request at octave dot org Mon Feb 13 13:11:11 2006 Subject: Re: Handle graphics plotting functions From: Shai Ayal To: Sebastien Loisel Cc: octave-graphics Date: Mon, 13 Feb 2006 21:09:23 +0200 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 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