GRASS GIS wrote:
#104: saving display to tiff or ppm garbled when NVIZ is not top window
----------------------+-----------------------------------------------------
Reporter: dylan | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: NVIZ openGL
----------------------+-----------------------------------------------------
Comment (by dylan):
Some updates (2008-03-26 SVN) & "nvidia" driver with DRI/GLX enabled.
1. export to full-res PPM, no error messages but results in black image.
------------------------------------------
Creating PBuffer Using GLX 1.3
Final Assembled Image will be 3185 x 4096
Destroy pbuffer
------------------------------------------
Okay; I'll try to get the nvidia driver up and running so that I can
look into this.
2. set env. variables:
export GRASS_NO_GLX_PIXMAPS=TRUE
export GRASS_NO_GLX_PBUFFERS=TRUE
Can you try the GLX Pixmap case, i.e.
export GRASS_NO_GLX_PBUFFERS=TRUE
export -n GRASS_NO_GLX_PIXMAPS
?
That's the case that's looking like it might be the most reliable.
export to full-res PPM, resulting image is at the coarse grid resolution.
After setting the coarse resolution to 1 and the fine resolution to 1 the
output file appears to be correct.
The coarse resolution is probably a coincidence.
Certainly, the do_zoom.c code doesn't touch the grid resolution,
regardless of which rendering target is used.
It may be timing related. AFAICT, the UI code switches to coarse
resolution when certain events occur (e.g. drag), then switches back
to fine resolution once the UI is considered "idle".
------------------------------------------
Final Assembled Image will be 3909 x 4096
------------------------------------------
It seems like Glynn's recent changes + setting environmental variables is
the trick to getting things to work using the "nvidia" driver.
If both environment variables are set, it renders into the window then
reads the data from the screen. That method is the most compatible (it
doesn't require any OpenGL or GLX features beyond those which are
already required for interactive display), but it's also the most
error-prone.
In this sense, bug #104 is a "cantfix".
Using the view window for rendering image files will always have the
risk of some other application putting something (dialog, tooltip,
menu, etc) over the view window in the middle of the rendering
process.
The only reason why we support this method is that the other methods
all require specific GLX features which the X server and/or OpenGL
library might not provide (or, worse still, they may "provide" a
version which doesn't work; we handle the case where the feature isn't
available, we can't handle the case where it's available but doesn't
actually work).
--
Glynn Clements <glynn@gclements.plus.com>