interactive PyFerret FRAME graphic expands beyond window bounds

[AndrewWittenberg]

The following bug seems to only appear when running an interactive PyFerret session on a local machine with a local display. It does not show up when logged in remotely (via tigerVNC) to an office workstation, or when running PyFerret without a display (pyferret -nodisplay). It also does not show up in vanilla Ferret -- as expected, since Ferret uses a different graphics engine than PyFerret).

It seems like this could be the same as this issue noticed a year ago.

Demo: generate a simple plot, then dump it to a PNG file:

  NOAA/PMEL TMAP
  PyFerret v7.63 (optimized)
  Linux 3.10.0-1160.25.1.el7.x86_64 - 08/25/21
  21-Jun-22 14:13    

yes? use coads_climatology
yes? shade/l=1 sst
yes? frame/file=frame.png

Here is what appears on the screen (correct plot):

And here is what the FRAME command creates (incorrect plot), when running interactively with a local display:

The PNG image is the same size (in pixels) as the screen image, but the graphics have expanded to spill outside the plot boundaries, so that the bottom/right edges are now cropped out. This also happens with vector output from FRAME (pdf, ps).

On our "analysis" machines (different than our workstations) we additionally get the following errors from the above SHADE command:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

Again, if logged in remotely, there are no problems and no errors, and the FRAME results are identical to what appears on the screen. So it's possible that this bug went unnoticed during the 2-year COVID pandemic when we were all at home, only to cause problems once we all started coming back into the office. If so, then the bug might have crept in anytime during the past two years.

Several of us at GFDL can confirm this bug, running with diverse environments. Developers: can you duplicate these results, when in-person at your office workstation? If not, we can try to send more information on our environment.

[AndrewWittenberg]

From Hans Vahlenkamp at GFDL:

"I have two monitors on my GFDL workstation, one has 1920x1200 resolution and one has 3840x2160 resolution. I found that the output image file was normal when the plot window was displayed on the 1920x1200 monitor. However, the output image file had the cropping problem when the plot window was displayed on the 3840x2160 monitor. So, the monitor resolution does have an impact as was suggested in the ferret mailing list.

I also found that the output image file cropping problem did not occur when running in a VNC session even when the vncviewer window is expanded to a very large size on the 3840x2160 monitor."

[seasage]

Hi @AndrewWittenberg,

Thanks for bringing this to my attention, and providing those details. I suspect that this is similar to an issue that appeared in the user list awhile back, though at the time it appeared to be specific to MacOS. Since I develop on a mac, I was able to recreate the issue then, and if I'm correct that means I can recreate this issue.

I will follow up with you via email if I need more details about the particulars of your set-up, but given that this may not be specific to an OS, and is not specific to a display, it gives me a few ideas of where to look and how to address this mismatch between the plotting resolution and frame dimensions.

If you're interested, the issue discussion in the mailing list can be found here: https://www.pmel.noaa.gov/maillists/tmap/ferret_users/fu_2019/msg01003.html and here: https://www.pmel.noaa.gov/maillists/tmap/ferret_users/fu_2019/msg00900.html

It may also be worth noting that some users have circumvented this issue by using versions prior to v7.6.0 or by not plotting interactively.

[AndrewWittenberg]

Another GFDL user (John Dunne) ran into this recently. Any progress to report? @eugeneburger @seasage