Sun, Feb 1 2004
11:57:43
|
|
Request created by guest (as #2306)
|
|
Subject: nviz image dump at max. resolution PPM
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
Hi,
The image dump option in NVIZ at max. resolution (PPM) produces an incorrect
file with narrow, colored horizontal strips across the image. I am saving a huge
grid at max. resolution 4096x2530.
Apparently, this option saves file using tiles that are not sewn correctly. However
this bug is only in a newer CVS version of grass5.3 (in my case Oct. 11, 2003).
grass5.0.0 uses a different procedure that works OK.
Jaro |
|
Thu, Jun 17 2004
15:56:28
|
|
Request created by guest (as #2490)
|
|
Subject: Nviz 2.2 crash in GRASS 5.3 executing the max-resolution image dump
as PPM
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: GRASS 5.3
In GRASS 5.3 (SuSE 8.2) the high-resolution Nviz2.2 image dump as PPM file (system
switched to mesasoft) causes the crash of the program and this error message
follows:
Creating PBuffer Using GLX 1.3
child killed: segmentation violation
while executing
"exec /usr/local/grass53/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass53/etc/nviz2.2/scripts/nviz2.2_scr
ipt
-q -name NVIZ >&@stdout"
("eval" body line 1)
invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script
$argv -name NVIZ >&@stdout"
invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script
-name NVIZ >&@stdo..."
(file "/usr/local/grass53/bin/nviz" line 16).
No problems for the dumps at standard resolution.
In GRASS 5.0.3 Nviz, compiled on the same configuration, the high-resolution
dump works fine.
Regards
Stefano Perona
|
|
Tue, Aug 31 2004
01:58:15
|
|
Comments added by hbowman (as #2490)
|
|
see the later parts of this thread:
http://thread.gmane.org/gmane.comp.gis.grass.devel/4547
Hamish
|
|
Fri, Sep 17 2004
10:24:08
|
|
Comments added by hbowman (as #2490)
|
|
does it work now with the latest version from CVS?
Hamish
|
|
Mon, Feb 28 2005
22:03:19
|
|
Request created by pcavallini
|
|
Subject: NVIZ max PPM dump fails when window is resized
Grass 6.0beta2 from Debian testing
Dumping at max resolution does not work if I resize NVIZ monitor; it
produces a number of files:
-rw-r--r-- 1 paolo paolo 3133457 2005-02-26 11:05 provamax2_1_1.ppm
-rw-r--r-- 1 paolo paolo 3133457 2005-02-26 11:05 provamax2_1_2.ppm
-rw-r--r-- 1 paolo paolo 14 2005-02-26 11:05 provamax2_1_3.ppm
-rw-r--r-- 1 paolo paolo 3130385 2005-02-26 11:05 provamax2_2_1.ppm
-rw-r--r-- 1 paolo paolo 3130385 2005-02-26 11:05 provamax2_2_2.ppm
-rw-r--r-- 1 paolo paolo 14 2005-02-26 11:05 provamax2_2_3.ppm
-rw-r--r-- 1 paolo paolo 15 2005-02-26 11:05 provamax2_3_1.ppm
-rw-r--r-- 1 paolo paolo 15 2005-02-26 11:05 provamax2_3_2.ppm
-rw-r--r-- 1 paolo paolo 12 2005-02-26 11:05 provamax2_3_3.ppm
-rw-r--r-- 1 paolo paolo 0 2005-02-26 11:05 provamax2.ppm
-rw-r--r-- 1 paolo paolo 0 2005-02-26 11:05 provamax2tmp1.ppm
-rw-r--r-- 1 paolo paolo 0 2005-02-26 11:05 provamax2tmp2.ppm
-rw-r--r-- 1 paolo paolo 0 2005-02-26 11:05 provamax2tmp3.ppm
Of these, the largest are cuts from the whole image.
This is the error output:
nviz elevation=t_dtm@PERMANENT
Loading Data
Update elev null mask
Loading Data
translating colors from fp
Xlib: extension "XFree86-DRI" missing on display ":0.0".
recalculating normals...
Row 100
Row 200
Creating PBuffer Using GLX 1.3
Create PixMap Using GLX 1.1
Final Assembled Image will be 1673 x 2048
Writing Tile 1 of 9
Writing Tile 2 of 9
Writing Tile 3 of 9
Writing Tile 4 of 9
Writing Tile 5 of 9
Writing Tile 6 of 9
Writing Tile 7 of 9
Writing Tile 8 of 9
Writing Tile 9 of 9
Assembling Tiles
Destroy Pixmap and GLXPixmap
Creating PBuffer Using GLX 1.3
Create PixMap Using GLX 1.1
Final Assembled Image will be 2048 x 2039
Writing Tile 1 of 9
Writing Tile 2 of 9
Writing Tile 3 of 9
Writing Tile 4 of 9
Writing Tile 5 of 9
Writing Tile 6 of 9
Writing Tile 7 of 9
MALLOC Failed
Writing Tile 8 of 9
MALLOC Failed
Writing Tile 9 of 9
Assembling Tiles
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: junk in file where an integer should be
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: EOF / read error reading magic number
pnmcat failed to create assembled images
Check that pnmcat is installed and path is set
Destroy Pixmap and GLXPixmap
I also get an error window:
invalid command name ".dialog0.pw.f1.frame.win.text"
If it's a resize problem only, it should be easy to fix it by making the
monitor of fixed size.
=======================
Help from Bob Covill:
It appears from the output that your system could not alocate
enough memory to combine the tile images. With the max size image, a
seies of tiles are saved and then pasted together into a sinle image.
From the files below this would be done with ...
pnmcat -lr provamax2_1_1.ppm provamax2_1_2.ppm provamax2_1_3.ppm >
provamax2tmp1.ppm
These left to right (-lr) strips are then combined into the final image.
From the comments below it looks like pnmcat could not malloc enough
memory. If possible try combining the images on another system or with a
different (less memory intensive) software package. It would probably be
helpful in the future to add an option that allows the user to choose
the ouput image size up to the maximum allowable. The curent default is
to automatically draw the maximum allowable size the the OpenGL
configuration supports.
|
|
Mon, Feb 28 2005
22:06:52
|
|
Request created by pcavallini (as #3042)
|
|
Subject: NVIZ max PPM dump include unwanted images
Grass6.0beta2 from Debian testing.
If I switch to another window when dumping, the dump reflects the new
window instead of the NVIZ monitor. This should be made clear to the user
(a "Don't move" warning).
========================
help from Bob Covill:
Minimize the main (visible) window before creating the off-screen context.
Because of callbacks to the main window it can sometimes replace the
off-screen context by simply moving the mouse across it. A pop-up window
would probably be helpful in this case inform
the user to first minmize the main window. |
|
Mon, Oct 17 2005
14:38:46
|
|
Area changed to grass5.0 by msieczka (as #2490)
|
|
Mon, Oct 17 2005
14:39:02
|
|
Area changed to grass5.4 by msieczka (as #2490)
|
|
Wed, Apr 5 2006
11:14:31
|
|
Mail sent by hbowman (as #2490)
|
|
NVIZ doesn't crash, but it doesn't make a .ppm either:
% Creating PBuffer Using GLX 1.3
Create PixMap Using GLX 1.1
Final Assembled Image will be 2048 x 2048
Writing Tile 1 of 9
Writing Tile 2 of 9
Writing Tile 3 of 9
Writing Tile 4 of 9
Writing Tile 5 of 9
Writing Tile 6 of 9
Writing Tile 7 of 9
Writing Tile 8 of 9
Writing Tile 9 of 9
Assembling Tiles
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: EOF / read error reading magic number
pnmcat failed to create assembled images
Check that pnmcat is installed and path is set
Destroy Pixmap and GLXPixmap
what's left over:
$ ls -hs1
total 13M
0 testbig.ppm
3.1M testbig_1_1.ppm
3.1M testbig_1_2.ppm
4.0K testbig_1_3.ppm
3.1M testbig_2_1.ppm
3.1M testbig_2_2.ppm
4.0K testbig_2_3.ppm
4.0K testbig_3_1.ppm
4.0K testbig_3_2.ppm
4.0K testbig_3_3.ppm
0 testbigtmp1.ppm
0 testbigtmp2.ppm
0 testbigtmp3.ppm
I do have pnmcat installed, I zoomed in so all tiles should contain data.
Hamish
|
|
Wed, Apr 5 2006
11:15:49
|
|
Request 2306 merged into 2490 by hbowman (as #2306)
|
|
Wed, Apr 5 2006
11:23:44
|
|
Request 2490 merged into 3041 by hbowman (as #2490)
|
|
Wed, Apr 5 2006
11:26:34
|
|
Subject changed to NVIZ max PPM dump fails to construct image by hbowman
|
|
Wed, Apr 5 2006
11:34:21
|
|
Mail sent by hbowman
|
|
$ pnmcat -lr testbig_1_1.ppm testbig_1_2.ppm testbig_1_3.ppm > testbigtmp1.ppm
pnmcat: Zero byte allocation
Memory isn't the problem, I've got 2gig RAM + 2gig swap.
"testbig_1_3.ppm" is a problem. 14 bytes.
$ pnmtopng testbig_1_3.ppm > tb3.png
pnmtopng: Zero byte allocation
The file is bogus.
Moreover if I look in _1_1.ppm and _1_2.ppm I see some bizare and chopped
rendering of my other virtual workspaces, not parts of a 3D surface...
Hamish
|
|
Fri, Apr 7 2006
06:24:17
|
|
Request 3042 merged into 3041 by hbowman (as #3042)
|
|
Fri, Apr 7 2006
07:33:13
|
|
Mail sent by hbowman
|
|
"help from Bob Covill:
Minimize the main (visible) window before creating the off-screen context.
Because of callbacks to the main window it can sometimes replace the
off-screen context by simply moving the mouse across it. A pop-up window
would probably be helpful in this case inform
the user to first minmize the main window."
If I minimize the main nviz window while it's asking me for a filename I still
get a corrupted ppm.
After this is fixed, can we pipe the final image through pnmtopng
automatically as 1) .ppm is huge and 2) we are using netpbm tools via system()
calls anyway so it is no more burden.
Hamish
|
|
Mon, Jul 24 2006
19:13:22
|
|
Mail sent by guest
|
|
Glynn Clements wrote on the garss dev list:
<quote>
As I have pointed out before, the problems with image dumping are due
to this:
# Set the cancel function for drawing
Nset_cancel_func update
This simply won't work.
Calling "update" can result in arbitrary event handlers being called.
Some of them (i.e. almost anything related to the Togl canvas) will
result in changes to the OpenGL context which will break the rendering
performed by the image dumping code.
Either the cancellation function will have to restore the OpenGL state
(and possibly some NVIZ state) before returning, or the OGSF library
will need to be modified to allow long rendering tasks to be performed
incrementally (i.e. replacing do-it-all with separate
begin/do-one-part/end operations).
Or, alternatively, you'll just have to live with the UI being
unresponsive during image dumping.
</quote>
Maciek
|
|
Tue, Aug 29 2006
10:39:23
|
|
Comments added by hbowman
|
|
From: Hamish <hamish_nospam yahoo.com>
Subject: Re: [GRASS-user] [bug #3041] nviz max resolution ppm image dump
Date: Tue, 29 Aug 2006 18:06:08 +1200
To: William Hargrove <hnw fire.esd.ornl.gov>
William Hargrove wrote:
> >>My nviz dies with a segfault when I try to dump an image as maximum
> >>resolution ppm.
> >>
> >>I have this same problem with grass 6.1 under FC 5, and under grass
> >>5.4 under FC 4.
..
> >>I can dump the other formats just fine.
> >>
> >>The map products look great on the screen, but aren't much use if I
> >>can't get them into a high-res image file.
> >>
> >>Does anyone have any advice on this problem?
Hamish wrote:
> >what's the date on the 6.1? 6.1.0 or 6.1-cvs? This was an old known
> >problem on 64bit &/or big endian (Mac G5), I had thought that it was
> >fixed by Glynn & crew some months ago.
I guess it is this bug after all:
> > http://intevation.de/rt/webrt?serial_num=3041
William Hargrove wrote:
> This is 6.1.0 built from source, running under 64-bit FC 5.
>
> Here is what happens when I try to dump a max-res ppm:
>
> recalculating normals...
> recalculating normals...
> Diagnostic: invalid command name "Nviz_animation_save" -- Save
> procedure for panel animation may not be defined
> Diagnostic: invalid command name "Nviz_kanimator_save" -- Save
> procedure for panel kanimator may not be defined
> Diagnostic: invalid command name "Nviz_query_save" -- Save procedure
> for panel query may not be defined
> Diagnostic: invalid command name "Nviz_sdiff_save" -- Save procedure
> for panel sdiff may not be defined
> Diagnostic: invalid command name "Nviz_label_save" -- Save procedure
> for panel label may not be defined
> Diagnostic: invalid command name "Nviz_scale_save" -- Save procedure
> for panel scale may not be defined
> Diagnostic: invalid command name "Nviz_pos_save" -- Save procedure
> for panel pos may not be defined
> Diagnostic: invalid command name "Nviz_resize_save" -- Save procedure
>
> for panel resize may not be defined
> Diagnostic: invalid command name "Nviz_pick_save" -- Save procedure
> for panel pick may not be defined
> Diagnostic: invalid command name "Nviz_highlight_save" -- Save
> procedure for panel highlight may not be defined
> Creating PBuffer Using GLX 1.3
> Final Assembled Image will be 1 x 1
> Writing Tile 1 of 1
> Assembling Tiles
> GLX -- destroy pbuffer
> ./donviz: line 2: 10088 Segmentation fault nviz
> elevation=elev48.new color=neon2.25
> vector=states100,neondomains_states
>
> Any ideas?
I get a segfault too: (32bit P4, 2gig RAM, Debian/stable)
Speafish with nviz window made to be large:
G63> nviz elevation.10m
Loading Data
Update elev null mask
Loading Data
translating colors from fp
recalculating normals...
r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL 8260df0
r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL 8260df4
r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL 8260df8
r200_makeX86Normal3fv done
% recalculating normals...
Creating PBuffer Using GLX 1.3
Create PixMap Using GLX 1.1
Final Assembled Image will be 1935 x 2048
Writing Tile 1 of 9
Writing Tile 2 of 9
Writing Tile 3 of 9
MALLOC Failed
Segmentation fault
(hard to replicate)
The "MALLOC Failed" message comes from lib/ogsf/gsd_prim.c
/************************************************************************/
int gsd_writeView(unsigned char **pixbuf, unsigned int xsize,
unsigned int ysize)
{
/* Malloc Buffer for image */
*pixbuf = malloc(xsize * ysize * 4);
if (!*pixbuf) {
fprintf(stderr, "MALLOC Failed\n");
return (0);
}
/* Read image buffer */
glReadBuffer(GL_FRONT);
/* Read Pixels into Buffer */
glReadPixels(0, 0, xsize, ysize, GL_RGBA, GL_UNSIGNED_BYTE, *pixbuf);
return (1);
}
/************************************************************************/
with window left at starting size: [note larger "Final Assembled Size"]
G63> nviz elevation.10m
Loading Data
Update elev null mask
Loading Data
translating colors from fp
recalculating normals...
r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL 82613f8
r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL 82613fc
r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL 8261400
r200_makeX86Normal3fv done
% Creating PBuffer Using GLX 1.3
Create PixMap Using GLX 1.1
Final Assembled Image will be 2048 x 2048
Writing Tile 1 of 9
Writing Tile 2 of 9
Writing Tile 3 of 9
Writing Tile 4 of 9
Writing Tile 5 of 9
Writing Tile 6 of 9
Writing Tile 7 of 9
Writing Tile 8 of 9
Writing Tile 9 of 9
Assembling Tiles
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: Zero byte allocation
pnmcat failed to create assembled image
Check that pnmcat is installed and path is set
pnmcat: EOF / read error reading magic number
pnmcat failed to create assembled images
Check that pnmcat is installed and path is set
Destroy Pixmap and GLXPixmap
no segfault, NVIZ keeps running, these files are left behind:
(easy to replicate)
0 Aug 29 17:24 spearNVhi2.ppm
3145745 Aug 29 17:24 spearNVhi2_1_1.ppm
3145745 Aug 29 17:24 spearNVhi2_1_2.ppm
14 Aug 29 17:24 spearNVhi2_1_3.ppm
3145745 Aug 29 17:24 spearNVhi2_2_1.ppm
3145745 Aug 29 17:24 spearNVhi2_2_2.ppm
14 Aug 29 17:24 spearNVhi2_2_3.ppm
14 Aug 29 17:24 spearNVhi2_3_1.ppm
14 Aug 29 17:24 spearNVhi2_3_2.ppm
11 Aug 29 17:24 spearNVhi2_3_3.ppm
0 Aug 29 17:24 spearNVhi2tmp1.ppm
0 Aug 29 17:24 spearNVhi2tmp2.ppm
0 Aug 29 17:24 spearNVhi2tmp3.ppm
0 Aug 29 17:30 spearNVhi3.ppm.ppm
assembly of rows then full image fail as partials are not valid images
(14 byte ones). Images with data assemble, but contain random x-window
buffer weirdness: multi-virtual-desktop collages.
Summary: the partial tiles are broken.
I haven't tried it with just one workspace.
minimizing the NVIZ window (before clicking "ok" for the output
filename) gives the same result.
at the end of the bug report Glynn offers a reason, but I have no idea
where to go from there. Dumb debugging effort: I still get the broken
result if I comment out "Nset_cancel_func update" in
visualization/nviz/scripts/nviz2.2_script
and rebuild nviz.
?
Hamish
|
|
Tue, Aug 29 2006
14:12:23
|
|
Comments added by hbowman
|
|
From: Bob Covill
Cc: GRASS developers list
Date: Tue, 29 Aug 2006 08:57:37 -0300
Hi Hamish,
I suspect there are a few bugs with some of the math in this. The best
place to start looking is Nstart_zoom_cmd in do_zoom.c (nviz/src). The
off-screen stuff was generating the MALLOC error for me this morning.
After the off-screen buffer was created the maxx and maxy returned were
incorrect which resulted in negative numbers being passed to malloc
which of course produced an error. I disabled the off-screen stuff and
it worked fine.
To debug this I would first start by disabling the off-screen stuff in
Nstart_zoom and draw the images directly. Also, check the dimensions
that are being calculated and passed to GS_write_zoom.
Hope this helps.
--
Bob |
|
Sun, Sep 3 2006
08:00:20
|
|
Comments added by hbowman
|
|
[Fwd from grass-dev mailing list]
Begin forwarded message:
Date: Fri, 1 Sep 2006 16:59:16 +0100
From: Glynn Clements
Subject: Re: [GRASS-dev] Re: [GRASS-user] [bug #3041] nviz max resolution ppm
image dump
Hamish wrote:
> > > > > With off-screen rendering disabled, I get good results with
> > > > > either of the above var_i calculations.
> > > >
> > > > The off-screen rendering draws to the back-buffer, GS_write_zoom()
> > > > dumps the front buffer. Also, Create_OS_Ctx() hides the Togl
> > > > canvas (presumably to prevent expose events from trashing the
> > > > OpenGL state during off-screen rendering), so it probably isn't
> > > > usable for rendering.
> > > >
> > > > Does this help?
> > > >
> > > > diff -u -r2.6 do_zoom.c
> > > > --- visualization/nviz/src/do_zoom.c 9 Jul 2006 08:58:40 -0000 2.6
> > > > +++ visualization/nviz/src/do_zoom.c 31 Aug 2006 12:58:16 -0000
> > > > @@ -325,6 +325,9 @@
> > > > }
> > > > #endif
> > > >
> > > > + if (!pbuffer && !glxpixmap)
> > > > + return 1;
> > > > +
> > > > /* hide togl canvas before init_ctx
> > > > * This prevents bindings from re-initializing
> > > > * togl */
> > >
> > > Nope. No change.
> >
> > Did you try with GRASS_NO_GLX_{PBUFFERS,PIXMAPS} set?
> >
> > With those set, and the above patch, Create_OS_Ctx() should
> > essentially be a no-op.
>
>
> I didn't. I have now and it renders correctly; you see each panel being
> rendered in the NVIZ window.
>
> i.e. : This works
> + if (!pbuffer && !glxpixmap)
> + return 1;
> and
> export GRASS_NO_GLX_PIXMAPS=TRUE
> export GRASS_NO_GLX_PBUFFERS=TRUE
>
>
> OR making this test always false makes it work:
>
> /* create off-screen context if possible */
> #if defined(OPENGL_X11) && (defined(HAVE_PBUFFERS) || defined(HAVE_PIXMAPS))
>
> it fails with: (random bits of old windows in built panels)
> + if (!pbuffer && !glxpixmap)
> + return 1;
> and
> unset GRASS_NO_GLX_PIXMAPS
> export GRASS_NO_GLX_PBUFFERS=TRUE
>
>
> it fails with: (mostly black with some color stripes in built panels)
> + if (!pbuffer && !glxpixmap)
> + return 1;
> and
> export GRASS_NO_GLX_PIXMAPS=TRUE
> unset GRASS_NO_GLX_PBUFFERS
IOW, neither pBuffers nor GLX Pixmaps work. FWIW, they don't work for
me either.
The existing code (minus the patch) doesn't correctly handle the case
where off-screen rendering is requested but both mechanisms fail (or
are disabled by the environment variables).
I'll commit the patch, so that disabling off-screen rendering at
run time works.
I could invert the sense of the tests, so that you have to
specifically request it. However, that essentially guarantees that the
off-screen rendering won't get any significant amount of testing.
> > > Does max res PPM dump work for anybody? (ie is it a platform
> > > dependent thing)
> > >
> > > Shall we disable offscreen rendering for the 6.2 release branch in
> > > case it doesn't get fixed in time for release?
> >
> > It should suffice to ensure that it can be disabled at run time.
>
> or by packagers (say if it's broken for all MacOSX)
There's no way of knowing that. Even if you tested it on every
possible software/hardware combination currently available, you don't
know whether it will start working with the next update.
So long as might work for someone, and everyone for whom it doesn't
work can effectively disable it, it should remain.
The only valid reason for using compile-time tests is to prevent
errors which cannot be prevented at run-time, i.e. loading errors due
to the use of functions which may not exist on specific systems.
--
Glynn Clements <glynn gclements.plus.com>
|
|
Sat, Nov 4 2006
18:27:41
|
|
Mail sent by mneteler
|
|
Does this now work?
Markus
https://intevation.de/rt/webrt?serial_num=3041 |
|
Sun, Nov 5 2006
10:08:40
|
|
Mail sent by hofierka@geomodel.sk
|
|
Return-Path |
<hofierka@geomodel.sk>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Sun, 05 Nov 2006 10:08:33 +0100
|
From |
Jaro Hofierka <hofierka@geomodel.sk>
|
Subject |
Re: [bug #3041] (grass) NVIZ max PPM dump fails to construct image
|
In-reply-to |
<20061104172741.5C5CA101F02@lists.intevation.de>
|
Sender |
hofierka@geomodel.sk
|
To |
Markus Neteler via RT <grass-bugs@intevation.de>
|
Cc |
cavallini@faunalia.it, sperona1@tin.it, Helena Mitasova <hmitaso@unity.ncsu.edu>
|
Message-id |
<454DAA11.6010303@geomodel.sk>
|
MIME-version |
1.0
|
Content-type |
text/plain; charset=us-ascii; format=flowed
|
Content-transfer-encoding |
7BIT
|
X-Accept-Language |
en-us, en
|
User-Agent |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414
|
References |
<20061104172741.5C5CA101F02@lists.intevation.de>
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
|
X-Spam-Level |
|
Markus Neteler via RT wrote:
> Does this now work?
>
>
>
> Markus
>
>
>
> https://intevation.de/rt/webrt?serial_num=3041
>
Markus,
On my box it crashes in grass6.3 and also 6.1 even including the X-server.
Saving tiff files is OK.
Jaro
|
|
Thu, Mar 22 2007
05:32:43
|
|
Comments added by hbowman
|
|
Still broken for me. Debian/Sarge i686.
(output is collage of chunks of different workspaces)
Hamish
|
|
Thu, Mar 22 2007
06:35:45
|
|
Comments added by hbowman
|
|
but works fine if I do
export GRASS_NO_GLX_PIXMAPS=TRUE
export GRASS_NO_GLX_PBUFFERS=TRUE
before starting NVIZ.
If that works on all platforms, perhaps we should consider inverting the tests
for those in the release branch (so it works for users), but leave as-is in
HEAD (so it isn't forgotten by devels).
Hamish
|
|
Tue, Apr 24 2007
11:32:15
|
|
Comments added by hbowman
|
|
update:
Brad as made onscreen rendering the default in the 6.2 release branch, Glynn
continues to try stuff to fix it, as recorded on the grass-dev mailing list.
Hamish
|
|
Tue, Apr 24 2007
11:32:28
|
|
Priority changed to 80 by hbowman
|
|