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

[hamish]

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

[hamish]

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':'`

[glynn]

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.

[hamish]

diff between 6.5 and trunk lib/cairodriver/

[hamish]

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.

[glynn]

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.

[hamish]

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

[glynn]

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).

[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

[hellik]

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

[martinl]

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

[hamish]

Replying to martinl:

+1 for backport before 6.4.1

done in r44628 (but not tested)

Hamish

[martinl]

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?

[hamish]

Replying to hamish:

done in r44628 (but not tested)

tested; it's fixed.

Hamish