[mapserver-dev] Rendering issues (cairo and others)

[Tamas Szekeres]

Folks,

I wanted to prepare my daily built binaries
<http://vbkto.dyndns.org/sdk/>with cairo rendering support on Windows.
In this regard the following
dependencies have been compiled.

pixman-0.20.0 (with no MMX and SSE2 support at this stage)
cairo-1.10.0 with the following features:

CAIRO_HAS_WIN32_SURFACE 1
CAIRO_HAS_WIN32_FONT 1
CAIRO_HAS_PNG_FUNCTIONS 1   --> with libpng 1.2.35
CAIRO_HAS_FT_FONT 1                   --> with freetype 2.3.9
CAIRO_HAS_FC_FONT 1                  --> with fontconfig 2.6.0
CAIRO_HAS_PS_SURFACE 1          -->zlib 1.2.3
CAIRO_HAS_PDF_SURFACE 1
CAIRO_HAS_SVG_SURFACE 1
CAIRO_HAS_IMAGE_SURFACE 1
CAIRO_HAS_RECORDING_SURFACE 1
CAIRO_HAS_USER_FONT 1
CAIRO_HAS_INTERPRETER 1

Having the configuration above with mapserver-trunk, I always get a blank
image with no features drawn on it regardless of the layer type.
Do you have any idea what could be wrong with this or what else should be
tested to identify the problem?

Further questions/problems:

1. Would it be reasonable to include support for the cairo Win32 surface in
Mapserver?

2. I can see much of unimplemented functions with many of the vtable
renderers (like GD2) do we have a plan to add a reasonable implementation
here? There is quite some progress with this in sandbox/mapserver6, however
this version doesn't seem to compile on Windows at the moment. I also see
some additional dependency to giflib which should also be made conditional
in the build process.

3. I've also added a new vtable method in
r10698<http://trac.osgeo.org/mapserver/changeset/10698>in order to
support the renderer specific way to serialize the images.
Actually I'm not too satisfied with the signature of saveImage which if
pretty much predefined to save on a FILE handle, it would be much more handy
to save on a 'stream context structure' which could eventually be based on a
file handle, a memory buffer, stdout, whatever, something like we do with
msIOContext actually. For example with the GD driver, I would be in favour
of transferring the the gdIOCtx way of serializing the image to a stream
(msSaveImageGDCtx) which have been used for either the file based or the
memory based output recently.


The long and the short of it is, I think the new rendering approach is in a
good shape to fininsh up this phase and finalize a set of the features being
ready for the 6.0 release.  I'm confidently looking forward to have the
users start testing with these new features as soon as possible.


Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20101106/9f63efd8/attachment.html