<br><br><div class="gmail_quote">2010/11/9 thomas bonfort <span dir="ltr"><<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div>What is there to gain from using a win32 surface? (the question also<br></div>
stands for the xlib backend provided by cairo).<br>
I don't think it would be too complicated to add, probably just a<br>
question of adding an outputformat definition and a couple of support<br>
functions in mapcairo.c<br>
<div class="im"><br></div></blockquote><div><br>While I'm not too familiar in the cairo libs, I expect a couple of potential benefits for the windows users like:<br><br>- support for saving as the Windows Bitmap (BMP) format.<br>
- support for rendering onto the screen device context directly.<br>- support for rendering onto the printer device context directly.<br> <br>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.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">All of the work is in the mapserver6 sandbox for now. Can you give<br>
more information as to what doesn't compile, so I can move forward and<br>
merge it back into trunk. And yes, there's now a dependency on giflib<br>
for loading pixmaps, and libpng and libjpeg for pixmap loading and<br>
image saving<br>
<div class="im"><br></div></blockquote><div class="im"><br>I'll be trying to track this down and provide you with the error if I cannot find out a solution.<br> <br>
<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">saveImage with a FILE handle is the only function used by the<br>
non-mapscript code in mapserver. For the mapscript functions there's<br>
msSaveImageBuffer, which is also implemented for the plugin backends<br>
(<a href="http://trac.osgeo.org/mapserver/browser/sandbox/mapserver6/maputil.c#L747" target="_blank">http://trac.osgeo.org/mapserver/browser/sandbox/mapserver6/maputil.c#L747</a>).<br>
The actual saving is already abstracted to be able to write to a<br>
buffer or a stream<br>
(<a href="http://trac.osgeo.org/mapserver/browser/sandbox/mapserver6/mapimageio.c#L801" target="_blank">http://trac.osgeo.org/mapserver/browser/sandbox/mapserver6/mapimageio.c#L801</a>)<br>
although this might be refactored a bit to use an msIOContext.<br>
<br>
Where you thinking of something other than this?<br>
<div class="im"><br></div></blockquote><div><br>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).<br>
<br>Best regards,<br><br>Tamas <br></div></div><br>