Hi Alan After posting on the wx forum, I realised I had the full wx sourcecode (including wxGTK) on my system from their Git repo. A quick scan seems to have revealed the issue. Could you try the following test for me? In wxWidgets_dev.cpp on line 443, could you change wxBITMAP_SCREEN_DEPTH to 24.
I think the problem is that when creating the bitmap on Linux, wxWidgets tries to get the screen depth from the top level window, which doesn't exist in this case, whereas on Windows it creates a screen dc and uses this to get the depth. If the fix above works I'll report it as a wxWidgets bug. If this fix works then please feel free to commit it so we get things working again as soon as possible. Phil On 5 January 2016 at 13:17, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > Thanks Alan > Do you want me to revert the commit? > > This is obviously a wxWidgets thing. In order to determine the size of the > text I need a device context to do the calculation with. On windows there > seems to be no problem creating a memory device context within a console > application. But on Linux gdk obviously doesn't like it. > > I'll ask on the wxWidgets board if there is a workaround. > > Phil > ________________________________ > From: Alan W. Irwin > Sent: 04/01/2016 20:13 > To: Phil Rosenberg > Cc: PLplot development list > Subject: Re: Linux wxwidgets idle issue not solved for text- or > line-dominatedplots > > On 2016-01-04 12:46-0000 Phil Rosenberg wrote: > >> Hi Alan >> I have just committed a change that deals with getting text size >> without two-way communication between the viewer and the driver. The >> text size is now performed entirely within the driver. >> >> This significantly improves the qualitative responsiveness of running >> the examples. To compare, on my Windows system I created a shell >> script that just ran examples 01, 04, 08, 14, 16, 24 and 30 using >> -dev wxWidgets -np and another script that was identical but used -dev >> null Running these under Cygwin bash using time ./nameofscript.sh gave >> the following >> >> pre commit with -dev wxwidgets >> real 0m17.248s >> user 0m0.060s >> sys 0m0.262s >> >> post commit with -dev wxWidgets >> real 0m7.709s >> user 0m0.076s >> sys 0m0.260s >> >> with -dev null >> real 0m4.060s >> user 0m0.061s >> sys 0m0.292s >> >> So this has given more than a factor of two improvement for those >> examples and results in a time which is approximately a factor of two >> longer than doing no rendering at all. I would personally be quite >> happy with that given the overheads involved in executing the extra >> process and setting up the shared memory. >> >> I still haven't got easy access to my home Linux system as for some >> reason it will no longer connect to the internet (but will connect to >> the lan e.g. to load my router's setup page). I think I only have >> wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a >> sensible comparison. If you want to check things out on your Linux box >> then please let me know the results. > > The above timing results seem promising indeed, but the changed > version for current master tip (commit 10973c88c) segfaults here at > run time. Here are the relevant valgrind results for the compile flags > > software@raven> printenv |grep FL > CXXFLAGS=-g > CFLAGS=-g > FFLAGS=-g > > to help improve line number feedback from valgrind > > software@raven> valgrind --num-callers=40 examples/c/x00c -dev wxwidgets > ==2403== Memcheck, a memory error detector > ==2403== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==2403== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==2403== Command: examples/c/x00c -dev wxwidgets > ==2403== > > (process:2403): GLib-GObject-WARNING **: invalid (NULL) pointer instance > > (process:2403): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion > 'G_TYPE_CHECK_INSTANCE (instance)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: > assertion 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion > 'GDK_IS_COLORMAP (colormap)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: > assertion 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion > 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion > 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_window_new: assertion > 'GDK_IS_WINDOW (parent)' failed > ==2403== Invalid read of size 8 > ==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in > /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25) > ==2403== by 0x8C6E1DD: ??? (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x9CB8473: ??? (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD2086: g_signal_emit_valist (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD29DE: g_signal_emit (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x8C62063: gtk_widget_realize (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x7C5C0D9: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C622A8: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) > (wxwidgets_dev.cpp:443) > ==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174) > ==2403== by 0x4E571E9: plP_init (plcore.c:144) > ==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345) > ==2403== by 0x400A01: main (x00c.c:44) > ==2403== Address 0x18 is not stack'd, malloc'd or (recently) free'd > ==2403== > ==2403== > ==2403== Process terminating with default action of signal 11 (SIGSEGV) > ==2403== Access not within mapped region at address 0x18 > ==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in > /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25) > ==2403== by 0x8C6E1DD: ??? (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x9CB8473: ??? (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD2086: g_signal_emit_valist (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD29DE: g_signal_emit (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x8C62063: gtk_widget_realize (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x7C5C0D9: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C622A8: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) > (wxwidgets_dev.cpp:443) > ==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174) > ==2403== by 0x4E571E9: plP_init (plcore.c:144) > ==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345) > ==2403== by 0x400A01: main (x00c.c:44) > ==2403== If you believe this happened as a result of a stack > ==2403== overflow in your program's main thread (unlikely but > ==2403== possible), you can try to increase the size of the > ==2403== main thread stack using the --main-stacksize= flag. > ==2403== The main thread stack size used in this run was 8388608. > ==2403== > ==2403== HEAP SUMMARY: > ==2403== in use at exit: 417,068 bytes in 3,235 blocks > ==2403== total heap usage: 4,711 allocs, 1,476 frees, 849,590 bytes > allocated > ==2403== > ==2403== LEAK SUMMARY: > ==2403== definitely lost: 0 bytes in 0 blocks > ==2403== indirectly lost: 0 bytes in 0 blocks > ==2403== possibly lost: 41,636 bytes in 541 blocks > ==2403== still reachable: 363,912 bytes in 2,619 blocks > ==2403== suppressed: 0 bytes in 0 blocks > ==2403== Rerun with --leak-check=full to see details of leaked memory > ==2403== > ==2403== For counts of detected and suppressed errors, rerun with: -v > ==2403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > Segmentation fault > > For what it is worth, this was all done with the C 00 example modified > as follows to remove all text from the plot (because I decided to > check your new commit with this non-text case first). > > index aa4683c..1aaa4f2 100644 > --- a/examples/c/x00c.c > +++ b/examples/c/x00c.c > @@ -44,8 +44,8 @@ main( int argc, const char *argv[] ) > plinit(); > > // Create a labelled box to hold the plot. > - plenv( xmin, xmax, ymin, ymax, 0, 0 ); > - pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" ); > + plenv( xmin, xmax, ymin, ymax, 0, -2 ); > + //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" ); > > // Plot the data that was prepared above. > plline( NSIZE, x, y ); > > > Let me know if there is any other experiment (i.e., a specific gdb run) > that you need me to do to help you find and fix this issue. > > Alan > > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
