Opened 14 years ago

Closed 13 years ago

#1152 closed defect (fixed)

d.out.file + cairo: errors writing the image

Reported by: hamish Owned by: grass-dev@…
Priority: major Milestone: 6.4.1
Component: Display Version: unspecified
Keywords: d.out.file, cairo Cc:
CPU: All Platform: All

Description

Hi,

in 6.4/6.5svn d.out.file with -c for the Cairo driver is having problems writing to the file. ISTR this was discussed on the ML recently, with the explanation something like that d.mon start= returns without waiting?

G65> d.out.file -c landsat
Saving display from Monitor: [x0] to <landsat.png>.
Image size [1115 x 988]
 100%
ERROR: Cairo_draw_bitmap: Failed to create source
WARNING: Socket is already in use or not accepting connections.
WARNING: Use d.mon to select a monitor
ERROR: No graphics device selected
WARNING: Error - Monitor 'cairo' was not running
Screen export complete. (writing the file may take a small amount of time)
Image crop [1115 x 987]
Done.

the image is a large (7000x8000) raster with a d.grid and d.text decorations over the top of it. I tried pushing in a sleep 1 before each d.* command from d.save, but no luck.

on a simple low-res image it does fine, as does running with the regular PNG driver. same behavior on multiple machines & different linux distros. (deb/ubu)

perhaps the solution is setting one of the display driver direct rendering enviro variables?

?

thanks, Hamish

Attachments (1)

65to7_cairo.diff.bz2 (9.7 KB ) - added by hamish 14 years ago.
diff between 6.5 and trunk lib/cairodriver/

Download all attachments as: .zip

Change History (13)

comment:1 by hamish, 14 years ago

using sync instead of sleep seems to work, but I doubt it is the best solution or portable to MSys.

Index: d.out.file
===================================================================
--- d.out.file  (revision 43358)
+++ d.out.file  (working copy)
@@ -350,11 +350,21 @@
 
 if [ "$GIS_FLAG_T" -eq 1 ] ; then
    # skip flood filling of background
-   dsave=`d.save -a | grep -v '^d.erase'`
+   if [ "$GRAPHICS_DRIVER" != "cairo" ] ; then
+      dsave=`d.save -a | grep -v '^d.erase'`
+   else
+      #wait for it to catch up
+      dsave=`d.save -a | grep -v '^d.erase' | sed -e 's/^d\./sync; d./'`
+   fi
 else
-   dsave=`d.save -a`
+   if [ "$GRAPHICS_DRIVER" != "cairo" ] ; then
+      dsave=`d.save -a`
+   else
+      dsave=`d.save -a | sed -e 's/^d\./sync; d./'`
+   fi
 fi
 
+
 d.mon start=$GRAPHICS_DRIVER $BEQUIET
   # 'd.info -b' for white band removal
   BOX=`d.info -b | cut -f2 -d':'`

in reply to:  1 ; comment:2 by glynn, 14 years ago

Replying to hamish:

using sync instead of sleep seems to work

That's sheer coincidence. "sync" waits for modified blocks to be written to disk. This could take several seconds, or it could return immediately.

In this case, the problem is:

ERROR: Cairo_draw_bitmap: Failed to create source

The monitor process is terminating via G_fatal_error(). Once that happens, subsequent d.* commands will fail however long you wait. Using GRASS_RENDER_IMMEDIATE=TRUE will prevent this (the command provoking the error will fail, but subsequent commands will succeed), but that's a workaround. The fix is to sync the cairo driver to 7.0, where the issue has been fixed.

by hamish, 14 years ago

Attachment: 65to7_cairo.diff.bz2 added

diff between 6.5 and trunk lib/cairodriver/

in reply to:  2 ; comment:3 by hamish, 14 years ago

Keywords: d.out.file added; d out.file removed

Replying to glynn:

The fix is to sync the cairo driver to 7.0, where the issue has been fixed.

erm, the whole thing? (attached diff is 50k without the new files)

Hamish

ps- fwiw Markus has just backported the "Use 64-byte header to ensure frame buffer alignment (trac #937)" from 65 to 64.

in reply to:  3 comment:4 by glynn, 14 years ago

Replying to hamish:

The fix is to sync the cairo driver to 7.0, where the issue has been fixed.

erm, the whole thing? (attached diff is 50k without the new files)

No; the 7.0 version won't work as-is in 6.x due to the substantial changes to the graphics architecture.

I mean: modify lib/cairodriver/Draw_bitmap.c so that it resembles the version in 7.0, but not so much that it doesn't compile or run.

comment:5 by hamish, 14 years ago

lib/cairodriver/Draw_bitmap.c changes backported to 6.5svn in r43698.

in reply to:  2 ; comment:6 by glynn, 14 years ago

CPU: x86-64All
Platform: LinuxAll

Replying to glynn:

In this case, the problem is:

ERROR: Cairo_draw_bitmap: Failed to create source

BTW, this is a duplicate of #1123 (which I've closed as "duplicate", as this one has more content).

in reply to:  6 ; comment:7 by hamish, 14 years ago

Replying to glynn:

Replying to glynn: BTW, this is a duplicate of #1123 (which I've closed as "duplicate", as this one has more content).

ok, thanks. for the record the test case given in #1123 is the best way I know to trigger the bug. I've just tested in 6.5svn+the backported fix and it works, while relbr6.4 fails (as expected).

if someone else could test the 6.5svn version on another platforms (i.e. Mac and WinGrass) we can backport it to 6.4 as well.

I guess WinGrass users might have to select cairo mode from the wx GUI preferences?

Hamish

in reply to:  7 comment:8 by hellik, 14 years ago

Replying to hamish:

Replying to glynn:

Replying to glynn: BTW, this is a duplicate of #1123 (which I've closed as "duplicate", as this one has more content).

ok, thanks. for the record the test case given in #1123 is the best way I know to trigger the bug. I've just tested in 6.5svn+the backported fix and it works, while relbr6.4 fails (as expected).

if someone else could test the 6.5svn version on another platforms (i.e. Mac and WinGrass) we can backport it to 6.4 as well.

I guess WinGrass users might have to select cairo mode from the wx GUI preferences?

Hamish

AFAIK there's no cairo-support in WinGrass at the moment (see http://trac.osgeo.org/osgeo4w/ticket/72).

Helmut

in reply to:  7 ; comment:9 by martinl, 14 years ago

Replying to hamish:

if someone else could test the 6.5svn version on another platforms (i.e. Mac and WinGrass) we can backport it to 6.4 as well.

+1 for backport before 6.4.1

in reply to:  9 ; comment:10 by hamish, 14 years ago

Replying to martinl:

+1 for backport before 6.4.1

done in r44628 (but not tested)

Hamish

in reply to:  10 ; comment:11 by martinl, 13 years ago

Replying to hamish:

Replying to martinl:

+1 for backport before 6.4.1

done in r44628 (but not tested)

so can we close this ticket?

in reply to:  11 comment:12 by hamish, 13 years ago

Resolution: fixed
Status: newclosed

Replying to hamish:

done in r44628 (but not tested)

tested; it's fixed.

Hamish

Note: See TracTickets for help on using tickets.