#380 wxt as a separate process, to make it work on MacOS

closed-out-of-date
nobody
None
5
2012-03-25
2008-04-24
No

Here is a patch to modify the wxt terminal to work as an separate process, in a similar way as the x11 terminal is doing. This is motivated by the following issues with the current GUI-loop-as-a-secondary-thread :

-wxt-on-macos fix would be hackish in that scheme, if not unfixable
(http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/6419),

-threaded event loop leads to bizarre moments of lag
(http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/7209),

-wxWidgets in general was not designed to be used with the main GUI loop in a separate thread.

So, with pieces of code to transfer messages beetween gnuplot core and a terminal, the wxt terminal can become a separate process and get rid of these issues. I hope others are not introduced.

My goal is also to write the code as generically as possible, as it could be shared with the x11 terminal or, say, future gtk or qt terminals.

Discussion

  • Timothée Lecomte

    Logged In: YES
    user_id=1333817
    Originator: YES

    I am attaching a first version of the patch, that applies and build cleanly on today's CVS.

    Currently, the patch introduces a new terminal that implements the idea, called "wxtp", instead of replacing the current "wxt". Of course, I plan to replace "wxt".

    The current state is the following:

    -unaddressed issue : I have not taken much time to see how it behaves together with SIGINT on gnuplot command line. Could messages be corrupted or something ? I have to do some testing.

    -todo 1: not tested on MacOS yet, but I am very confident that it will work out-of-the-box this time. I'm serious.
    -todo 2: the code relies on a Unix FIFO, so it most likely doesn't build on Windows. Hence wxt-ipc.c has to be implemented for Windows specifically, with sockets probably.
    -todo 3: I'd like the messaging interface not to reuse gnuplot code, so that it can be GPL or BSD licensed, and so that terminals can be written in Qt. Currently, the terminal still needs some definitions for encoding, colors, etc.
    -todo 4: optimization. Batching command together as x11 is doing, if I remember correctly. Also allocate memory more wisely in wxt-msg.c.

    - what's working : well, pretty much everything that's working with wxt currently. Of course, the graphics engine is the same, so the rendering is the same. Tricky features, such as enhanced text, or the "persist" option, work too.

    Please test (on MacOS if you can!) and comment. Thanks.
    File Added: wxt-as-process-20080424.diff

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817
    Originator: YES

    Here is an updated version of the patch.

    Changes:
    - cleanups, cleanups, cleanups
    - SIGINT behaviour is ok, similar to the way the x11 terminal works (ctrl-c in the console interrupts any drawing in the terminal driver). The good news is that it's mostly a removal of a lot of code !

    I am still planning to work on this. The todo list hasn't changed much.
    Please note that, as of today's CVS, there's a almost-trivial reject in gp_cairo.c due to the recent addition of rgba images. I'll fix that reject in the next iteration.
    File Added: wxt-as-process-pre20080730.diff

     
  • Timothée Lecomte

    Today's patch is just updated to current CVS and applies cleanly. It is slightly simplified because of the modifications I have committed to the image code these last days.

    The todo has not changed, except that it now must include the following point :
    -synchronize with current wxt_gui.cpp, where changes have happened !

    The most important point in the todo list is optimizing the messaging layer, which is currently deadly slow.

     
  • Ben Abbott

    Ben Abbott - 2009-01-18

    I applied the patch to the current sources. Unfortunately, I encountered a problem building (likely unrelated). After "patch -p1 ...", and "./prepare", and "./configure", and then I "make" ...

    make all-recursive
    Making all in config
    make[2]: Nothing to be done for `all'.
    Making all in m4
    make[2]: Nothing to be done for `all'.
    Making all in term
    make[2]: *** No rule to make target `js/*.js', needed by `all-am'. Stop.
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

    What am I doing wrong?

     
  • Ethan Merritt

    Ethan Merritt - 2009-01-18

    Ben:
    The .../term/js subdirectory is brand new. In order to import it from the cvs repository you need to issue the command cvs update -d
    (I think -d is for "directory"). Once you actually have the directory on your machine, I think you will find that the prepare/configure/build process works without a hitch.

     
  • Ben Abbott

    Ben Abbott - 2009-01-19

    Thanks Ethan,

    I'm now able to build without trouble. Unfortunately, the wxt terminal does not work. Is wxt currently functional for anyone running OSX (leopard)?

    When I try it, the result is less than graceful

    Terminal type set to 'aqua'
    gnuplot> set term wxt
    Terminal type set to 'wxt'
    Options are '0'
    gnuplot> plot sin(x)
    /sw/bin/gnuplot: line 6: 90299 Bus error /sw/bin/gnuplotx "$@"

     
  • Ethan Merritt

    Ethan Merritt - 2009-01-19

    The wxt terminal has never worked under OSX; that was the motivation for this patch. The idea is to apply the patch and then test the replacement terminal, which is called 'wxtp' rather than 'wxt'. If/when it's working, it would replace the original wxt.

    I borrowed access to an OSX machine to try it. For me it compiled and linked without error. The new driver worked fine for display up to a point, but I could not give focus to the display window so I couldn't use the mouse. It failed when it reached the image demos, where it started throwing a stream of memory allocation errors. Thimothée is looking into it, but if you have additional or different results to add I'm sure it would be useful feedback.

     
  • Ben Abbott

    Ben Abbott - 2009-01-19

    I'm running XQuartz 2.3.1 on Leopard 10.5.6 with wxgtk 2.8.7-19.

    When I set the terminal to 'wxtp', I still get errors but it is more graceful in its failure ;-)

    gnuplot> set term wxtp
    Terminal type set to 'wxtp'
    Options are '0'
    gnuplot> plot sin(x)
    fifo out path /tmp/wxtp-91980-out, fifo in path /tmp/wxtp-91980-in, fifo event path /tmp/wxtp-91980-event child path /sw/lib/gnuplot/4.3/gnuplot_wxt
    fifo out path /tmp/wxtp-91980-out, fifo in path /tmp/wxtp-91980-in, fifo event path /tmp/wxtp-91980-event
    gpterm_msg_receive : end of file 0
    Error in receiving font details from term
    warning: Too many axis ticks requested (>1e+01)
    warning: Too many axis ticks requested (>1e+01)
    warning: Too many axis ticks requested (>4)
    gnuplot> wxt communication error, not enough bytes read, 0

     
  • Nobody/Anonymous

    I'm attaching an updated patch.

    Changes :
    -fix most memory leaks (they were obvious)
    -make "wxtp" the default terminal when the patch is applied
    -synchronize with changes in wxt_gui.cpp since I forked from it
    -fix a major performance issue by using a double-ended queue instead of a doubly-linked list : appending to the latter is O(n) while appending to the former is just O(1).

    With this last change, performance of wxtp is almost on par with current wxt. For example, on my machine :
    $ time GNUTERM=wxtp gnuplot all.dem < /dev/null 2> /dev/null
    real 0m34.830s
    user 0m4.344s
    sys 0m4.152s
    $ time GNUTERM=wxt gnuplot all.dem < /dev/null 2> /dev/null
    real 0m28.227s
    user 0m18.177s
    sys 0m1.536s
    $ time GNUTERM=x11 gnuplot all.dem < /dev/null 2> /dev/null
    real 0m31.647s
    user 0m3.616s
    sys 0m1.364s

    For me, all.dem works perfectly on Linux.

    Updated TODO :
    -find an easy way to make a bundle out of it, so that the window can get its focus on MacOSX
    (for guidance, see :
    http://wiki.wxwidgets.org/WxMac_Issues#Building_a_MacOSX_application_bundle
    http://www.wxwidgets.org/docs/faqmac.htm
    http://supertuxkart.sourceforge.net/Building_and_packaging_on_OSX#Making_an_app_bundle
    http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX#Creating_an_.app_bundle
    )
    -port the IPC mechanism to windows
    -optimize the memory allocation in wxt_msg.c, so that we don't allocate piece by piece, but from time to time only

    That's it !

    If you can, please test on MacOSX that all.dem is executed and rendered correctly; and if you feel brave, try bundling it :)

     
  • Ethan Merritt

    Ethan Merritt - 2009-02-17

    Sorry for not reviewing this earlier. Here are some comments.
    Tested under Mandriva 2008, wxgtk 2.8.4

    Major

    The biggest issue is that the scaling has broken badly. I am guessing that all the problems below are due to a single bookkeeping error, and that the descriptions will offer a huge hint as to where it lies.

    - If I resize the plot window using the mouse, the plot itself resizes as I go. However, when I release the mouse and refresh the plot the new scale is lost. All subsequent plots are drawn at the original scale, and thus do not match the new window size. This makes resizing the window pointless, and is clearly a bug.

    - Probably the same bug as above - if I say "set term wxtp size xxx,yyy" then it opens a new plot window (even if the window is already present) but it creates it in the original size, not in the requested size. The plot itself, however, is drawn at the requested size, which means it does not fit in the window. Again, resizing the window using the mouse does not change the plot size.

    - Continuing on with the same scaling problem... If I control-C out of a script, the scale of the plot becomes unstable. Subsequent replots are drawn at different scales. This is really strange.

    - "reset" sometimes, but not always, changes the plot window size. It should never do this.

    - Curiously, if I kill a resized plot window manually, then next plot does remember the size of the window that was killed. So at least some part of the code correctly tracks the size of a manually resized window. It just doesn't seem to use that information when actually drawing the plot.

    ==> In trying to reproduce the above, I find that things are not consistent. Depending on the order of operations, sometimes "set term wxtp size xxx,yyy" *does* open the new plot window in the requested size. But it still fails to scale the plot appropriately.

    Less serious issues

    - The mouse ruler ('r' hotkey) does very strange things. It looks like the y axis coordinate readout is upside-down, and also I get spurious a diagonal line from the current mouse position.

    - Non-fatal compiler warnings:
    wxterminal/wxtp_core.c:182: warning: unused variable ‘old_window_number’
    wxterminal/wxtp_core.c:397: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:368: warning: unused variable ‘buffer0’
    wxterminal/wxtp_core.c:368: warning: unused variable ‘buffer’
    wxterminal/wxtp_core.c:443: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:541: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:636: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:644: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:647: warning: ‘return’ with no value, in function returning non-void
    wxterminal/wxtp_core.c:653: warning: ‘return’ with no value, in function returning non-void
    wxterminal/wxtp_core.c:743: warning: implicit declaration of function ‘rgb255maxcolors_from_gray’
    wxterminal/wxtp_core.c:750: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:737: warning: unused variable ‘buffer0’
    wxterminal/wxtp_core.c:737: warning: unused variable ‘buffer’
    wxterminal/wxtp_core.c:766: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:819: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:893: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:935: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:973: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:1015: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:1039: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:1089: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:1101: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:1113: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:1124: warning: ISO C90 forbids mixed declarations and code
    wxterminal/wxtp_core.c:1136: warning: ISO C90 forbids mixed declarations and code
    wxterminal/gp_cairo.c:1008: warning: unused variable ‘n’
    wxterminal/gp_cairo.c:1008: warning: unused variable ‘m’
    wxterminal/gp_cairo_helpers.c:62: warning: implicit declaration of function ‘gp_alloc’

     
  • Nobody/Anonymous

    I tried it on OS X and it compiled fine. However, it is still impossible to clic on anything in the terminal. I cannot give focus to the window...

    I remember having had similar issues with plain old WxWidgets apps. Launch it with ./executable and it will never let you access the window. Use ./executable & and it works fine.

     
  • Ethan Merritt

    Ethan Merritt - 2009-06-01
    • priority: 5 --> 9
     
  • Ethan Merritt

    Ethan Merritt - 2009-06-01

    In preparation for eventual release of gnuplot version 4.4, existing bugs and patchsets are being re-prioritized.

    I have chosen to use the following categories

    9 - should be included in 4.4.rc1 if possible
    7 - looks reasonable to me, but not high priority for 4.4.rc1
    5 - default priority for newly submitted patches
    2 - not under active consideration

    These are my personal ratings. If you want to argue for a different priority on one or more patches - go right ahead.

    Ethan Merritt (sfeam)

     
  • Ethan Merritt

    Ethan Merritt - 2010-08-11
    • priority: 9 --> 5
     
  • Ethan Merritt

    Ethan Merritt - 2012-03-25
    • status: open --> closed-out-of-date
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks