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

[Tamas Szekeres]

2010/11/9 thomas bonfort <thomas.bonfort at gmail.com>

> What is there to gain from using a win32 surface? (the question also
> stands for the xlib backend provided by cairo).
> I don't think it would be too complicated to add, probably just a
> question of adding an outputformat definition and a couple of support
> functions in mapcairo.c
>
>
While I'm not too familiar in the cairo libs, I expect a couple of potential
benefits for the windows users like:

- support for saving as the Windows Bitmap (BMP) format.
- support for rendering onto the screen device context directly.
- support for rendering onto the printer device context directly.

Some further coding may also be required to obtain the device context from
the user but it may probably be implementet in a reasonable way. However my
greatest problem at the moment is that I can obtain only blank images from
the cairo renderer compiled mapserver from trunk with cairo support.


All of the work is in the mapserver6 sandbox for now. Can you give
> more information as to what doesn't compile, so I can move forward and
> merge it back into trunk. And yes, there's now a dependency on giflib
> for loading pixmaps, and libpng and libjpeg for pixmap loading and
> image saving
>
>
I'll be trying to track this down and provide you with the error if I cannot
find out a solution.


saveImage with a FILE handle is the only function used by the
> non-mapscript code in mapserver. For the mapscript functions there's
> msSaveImageBuffer, which is also implemented for the plugin backends
> (http://trac.osgeo.org/mapserver/browser/sandbox/mapserver6/maputil.c#L747
> ).
> The actual saving is already abstracted to be able to write to a
> buffer or a stream
> (
> http://trac.osgeo.org/mapserver/browser/sandbox/mapserver6/mapimageio.c#L801
> )
> although this might be refactored a bit to use an msIOContext.
>
> Where you thinking of something other than this?
>
>
I understand the concept above, however we should be more permissive for a
renderer to allow to support their favourite saving approaches in addition
to exporting the image in memory using the generic way. For some renderers
in the future, I assume it may be faster to use a driver specific method for
example if the image compression is supported with hardware acceleration
etc. Another issue of mine was the lack of the support for saving the image
with the gd renderer currently (in mapserver-trunk).

Best regards,

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