Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#310 Make resize code in x11 terminal icccm compliant

closed-fixed
Ethan Merritt
None
5
2007-12-01
2006-12-13
Iain Murray
No

Earlier versions of gnuplot have caused my window manager (ion3) to use 100% CPU as it fought with gnuplot over its window size. For reasons I don't completely understand this no longer happens for me with the current CVS version, but the resize behavior still seems broken: the mouse coordinate text does not appear in the bottom left unless I manually resize the window first.

I believe both issues are due to the code violating this ICCCM rule:

"The response of the client to being resized should be to accept the size it has been given and to do its best with it. Clients must not respond to being resized by attempting to resize themselves to a better size."
--- http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.4

The attached patch attempts to make gnuplot deal with the size it has been given and removes the part of the code that attempts to resize itself in response to a resize event. This fixes all problems for me using gnuplot under ion, and does not cause any adverse effects that I have noticed.

As I don't feel I totally understand the gnuplot code I would appreciate someone checking this over for me. Then I'd feel happier submitting patches for the versions of gnuplot in the distributions that I use.

Thanks very much,
Iain.

Discussion

  • Iain Murray
    Iain Murray
    2006-12-14

    patch for icccm compliance when resizing (fixes bad interactions with ion)

     
    Attachments
  • Iain Murray
    Iain Murray
    2006-12-14

    Logged In: YES
    user_id=605054
    Originator: YES

    File Added: gnuplot_cvs_patch2

     
  • Ethan Merritt
    Ethan Merritt
    2007-01-29

    Logged In: YES
    user_id=235620
    Originator: NO

    I'll have a look at this patch when all the 4.2 release issues are settled.
    In general I'd like to be able to reproduce a problem before accepting a patch to fix it.

    Could you please provide more information about your X11 setup?
    What was the trigger that caused 100% CPU load - resizing the window manually? mousing? "set/unset mouse"?
    What is your x-server version?
    Have you tried gnuplot on any other window manager running on the same machine?
    Does OpenOffice work well on it? (This may sound like a strange question, but but Oo and gnuplot contain certain very similar work-arounds for buggy desktop environments. If this particular issue is something they've had to deal with, maybe we can look at their fix).

    Most importantly, I think - what earlier version of gnuplot was this problem occurring on? I might understand the change in behaviour better if I knew what time-frame to look for changes in the gnuplot_x11 source code.

     
  • Ethan Merritt
    Ethan Merritt
    2007-01-29

    • assigned_to: nobody --> sfeam
     
  • Iain Murray
    Iain Murray
    2007-02-01

    Logged In: YES
    user_id=605054
    Originator: YES

    Thanks for agreeing to look at this when you get time. I appreciate it.

    I believe this bug has been in gnuplot for a long time, although only when mouse support is enabled. Gnuplot from 2004-01-09 in CVS exhibits this bug. I'm afraid I can't get any early versions to compile on my computer: a combination of autoconf-hell and pickyness of recent gcc. However eye-balling CVS I believe the (cause of this) bug has been there since mouse support was first introduced, CVS tag GNUPOT_20000211.

    Some more information:

    I'm using the X server and ion3 provided by Ubuntu 6.10. I doubt the X server version is relevant, but here it is:
    vendor string: The X.Org Foundation
    vendor release number: 70101000
    X.Org version: 7.1.1
    I'm using ion3 version 3ds-20060524.

    Here is how I exhibit the bug under ion3:
    [Bring up a terminal on a tiled workspace]
    gnuplot
    set term x11
    plot x
    The mouse coordinates are not displayed in the bottom left of the plot as they would normally be. Pressing 'm' doesn't help. Resizing the window does cause the coordinates to be displayed. However pressing 'm' will confuse it again (cause the same infinite loop described below).

    The problem is much worse in the version of gnuplot that comes with Ubuntu (Version 4.0 patchlevel 0, last modified Thu Apr 15 14:44:22 CEST 2004) as a combination of ion3 and Xorg take up all my CPU. This is why I spent time looking into the bug. While the CPU issue has gone, the cause is still there and I believe worth fixing.

    This comment and the code beneath it rings alarm bells for me.
    /* most likely, it's a resize for showing/hiding
    * the status line: test whether the height is now
    * correct; if not, start another resize: */
    I don't believe it is good form to ever call XResizeWindow in response to a resize event. As my original post quoted, it violates the ICCCM. The window manager is allowed to disagree with the size and send its own resize event, the application must acquiesce to avoid creating an infinite loop. The code justifies this violation by thinking that it only does it when gnuplot caused the resize event in the first place. But this isn't necessarily true.

    Some background: ion is a window manager that keeps windows in tabbed panels that split up and use the entire screen. This means that a window can't resize itself because that would require moving the panels around and ion doesn't allow applications to do that. Just after creating a plot window, or just after pressing 'm' gnuplot tries to make the window bigger (or smaller) to show (or hide) the status line. Ion then sends a resize event telling gnuplot to be the size it wants, the size of the panel it is in. This means the window size coincidentally matches the test above the comment I've quoted. Gnuplot then wrongly assumes it generated the resize.

    To check this I inserted debug FPRINTF statements and saw that indeed, even in the CVS version, the XResizeWindow line is called repeatedly until I press 'm' or resize the plot. Quite what has changed so that 100% CPU isn't used I'm not sure --- but the infinite loop still seems to be there.

    My patch strips out the lengthy chunk of code that asks for resizing and nothing seems to break. So I don't understand why these extra resize events were considered necessary in the first place. There seems to be no need to *insist* on a particular size because when this code is removed gnuplot is able to make do with the size ion wants anyway.

    Yes gnuplot works fine when I run it under Gnome on the same machine. It also works fine if I run gnuplot on a floating desktop in ion where windows are free to take on any size. It is the normal (for ion) tiled desktops where the problem occurs. I don't /think/ the patch changes the behaviour of gnuplot in Gnome or floating desktops in ion: the window still changes size when it's allowed to, but rescales the plot to make room for the status line when it is not.

    While ion is very different to the most frequently used window managers, its author seems to pay close attention to the rules a window manager should obey. So I'm not sure "buggy desktop environment" is really the right terminology. Anyway, yes: openoffice.org works fine, at least superficially, under ion on my machine.

     
  • Iain Murray
    Iain Murray
    2007-06-06

    Logged In: YES
    user_id=605054
    Originator: YES

    Hi,

    Just thought I'd update you with the current status of this issue.

    The latest CVS version of gnuplot is still effected. I've now tried the latest version of the ion window manager (ion-3rc-20070506) and there are still problems.

    Currently I see the problem with the following procedure:
    set term x11
    plot x
    turn off mouse coords with 'm'
    note there is an empty gap where they were (when using ion tiled workspace)
    resize window to close gap
    try to turn mouse coords back on with 'm' (they won't appear until another window resize)

    This behaviour is slightly different to the last time I reported. I think the exact manifestation of the problem depends on the pixel-placement of the windows and exactly how the fight between the window manager and gnuplot starts.

    My patch still applies cleanly and still solves all problems under my setup.

    Iain.

     
  • Ethan Merritt
    Ethan Merritt
    2007-12-01

    • status: open --> closed-fixed
     
  • Ethan Merritt
    Ethan Merritt
    2007-12-01

    Logged In: YES
    user_id=235620
    Originator: NO

    Fixed (I hope!) by applying Thomas Orgis' patch #1836959.

     
  • Iain Murray
    Iain Murray
    2007-12-04

    Logged In: YES
    user_id=605054
    Originator: YES

    I haven't reviewed Thomas's patch, but CVS gnuplot now works fine in ion, so presumably it was good.

    Thanks,
    Iain.