Opened 16 years ago

Last modified 12 years ago

#1243 new defect

[Performance] gdImageStringFT called multiple time in msDrawTextGD.

Reported by: jlacroix Owned by: jlacroix
Priority: high Milestone: 6.0 release
Component: MapServer C Library Version: unspecified
Severity: normal Keywords:
Cc: woodbri@…, aboudreault, tbonfort, jmckenna

Description (last modified by tbonfort)

In bug 1224, I found out that in msDrawTextGD, gdImageStringFT is called 7 times
in a row to make the outline of the text. In 4.0 there were only three call to
this function. I suppose it's for a better outlining of labels.

This cause a problem, a performance lost. It depends on the mapfiles, but in the
GMap demo (around 14 labels), it results in a 15% performance lost.

With 4.0, for 50 call to
total: 6.18 sec.
in gdImageStringFT: 1.66 sec.

With 4.0:
total: 7.56
in gdImageStringFT: 2.51 sec.

Is there a way to reduce the cost of outlining?
To reduce the number of call?

Attachments (4)

outlines.png (5.2 KB) - added by jlacroix 16 years ago.
comparison between freetype outlines with stroker and current mapserver outline
mapgd.patch (2.1 KB) - added by jlacroix 16 years ago.
patch to use freetype oulines
gd.h.patch (1.0 KB) - added by jlacroix 16 years ago.
patch gd.h to use freetype outline
gdft.c.patch (2.5 KB) - added by jlacroix 16 years ago.
patch gdft.c to use freetype outline

Download all attachments as: .zip

Change History (28)

comment:1 Changed 16 years ago by jlacroix

blocked: 1224
Cc: mapserver-bugs@… added
I forgot to say that this lost is not caused by the antialiasing. The
antialiasing is expensive, but the same kind of performance lost is observed.

comment:2 Changed 16 years ago by sdlime

I'm all for finding a better way but I've not had any luck. I've been playing 
with this off and on for years. Ideally the outlining would be implemented 
very close to the GD/FT interface (i.e. GD should offer the effects: shadows 
and outlines, not MapServer. The additional calls are indeed for better 
outlining. With glyph caching it should not be that expensive.

Anyway, I'm open to suggestions...


comment:3 Changed 16 years ago by jlacroix

What is the original reason of the change from 3 to 7 calls? I did not check,
but is it possible to do less than 7 calls?

comment:4 Changed 16 years ago by sdlime

Status: newassigned
The reason for the change was to get better text outlines. It actually went 
from 4 to 8 calls I think. The outline is created by offsetting the text each 
of the 8 directions, used to be just 4. However, for some fonts that left gaps 
in the outline, most notably 'i' and 'l' with arial. It would probably by 
faster to render the text in the outline color once in a temporary image, then 
paste that image into the main image subsequent times. Could also try running 
a convolution filter on the temp image to achieve an effect. 

Let me play with it. May take a couple of days though.


comment:5 Changed 16 years ago by jlacroix

Milestone: 4.6 release
I think we should aim 4.6 with, at least to see if it's possible to gain speed
with the temporary image. I may have time to check it this week. I will assign
it to me if it's the case.

comment:6 Changed 16 years ago by sdlime

I have been thinking about this. The problem with a temporary image is that 
antialiasing falls apart. I think the solution lies either:

  - in modifications to GD or Freetype to allow for text effects upon initial 
  - perhaps trying to use a different font size to lay down the outline color

I've experimented with the latter before, but with older versions of Freetype, 
and found that simply scaling of labels did not work well.


comment:7 Changed 16 years ago by woodbri@…

Cc: woodbri@… added

comment:8 Changed 16 years ago by dmorissette

Using a different font size won't work unfortunately. I searched for "halo" and
freetype, and found the following post at

This is probably what we need: we could do the dilation (and antialias) in
MapServer on a pixmap that contains the rendered font, and possibly submit a
patch to to integrate this in future versions of GD.

Re: [Freetype] Halo(?) font/effect
From: 	Peter Montgomery
Subject: 	Re: [Freetype] Halo(?) font/effect
Date: 	Tue, 13 Apr 2004 23:50:45 -0700


> The effect (Called a 'halo font' by the end user - Not sure if that is the
> term or not) results in a ring (typically white) of a pixel or two being
> all the way around each character, almost as if the character was drawn on
> of a larger version of itself.
> So, I'm wondering if FreeType has any support for this feature, or if
> has suggestions about how to achieve this?  The best approach I've found
so far
> is to extract the curves of each character, draw them as (white) lines
with a
> thick lineweight, then proceed to draw the (black) character on top as per

You could also come at this from an image processing perspective.  Once you
have a bitmap of your string, perform a dilation of the image and then merge
that with the bitmap from Freetype.  I did a google search on the following

image dilation code

Here's a couple of hits that looked interesting:

This one has some source code:

This one shows some images of dilation, erosion, etc:

This is an open source image processing library that looked interesting and
contained various morphological functions such as dilation:


comment:9 Changed 16 years ago by jlacroix

While trying to test the code above I found two useful thread on the Freetype
mailing list:

[ft] Thick contours

[Freetype] using a Stroker to make a glyph border pixmap

I will give a try to the stroker stuff.

comment:10 Changed 16 years ago by jlacroix

Cc: steve.lime@… added
Owner: changed from sdlime to jlacroix@…
Status: assignednew
reassign to me to try the stroker stuff.

comment:11 Changed 16 years ago by jlacroix

Status: newassigned

comment:12 Changed 16 years ago by sdlime

Note that MapServer used to use the offset 4 times method described in the 
first thread, but found that insufficient, hence the 8 times now.


Changed 16 years ago by jlacroix

Attachment: outlines.png added

comparison between freetype outlines with stroker and current mapserver outline

comment:13 Changed 16 years ago by sdlime

That's good news. Can you post some examples? Also, some clarification on what 
exactly you are adding? There may be other uses... Are you changing MapServer 
(by just removing stuff) adding to GD, using new Freetype functions or what? I 
had problems getting to the URLs you referenced, on intermittent success.


comment:14 Changed 16 years ago by jlacroix

Sorry, there's no other real example other than what I attached to the bug. What
would you want, maybe I can quickly build an example.

Here what I changed:
Remove the outlining code. Since the outlining is done by GD, we do not need
this code.

I updated my freetype version to use the development version (snapshot available
on their website) instead of the last stable release (freetype 2.1.9). The
stroker code is stable only in the development version. It was fixed in august
2004, and there is no official release with the fixes.

I modified the gdImageStringFTEx function in GD 2.0.33. This function is used to
draw the text in GD. At some point in this function, the glyph are loaded from
freetype. It's there, before the drawing, that we need to include the stroker
code. This code simply load the outline of the glyph and make it thick. In
short, after the line:

          /* load and transform glyph image */
          FT_Get_Glyph (slot, &image);

You include:

FT_Glyph borderimg;
FT_Stroker stroker;

FT_Glyph_Copy(image, &borderimg);

FT_Stroker_New (face->memory, &stroker);
FT_Stroker_Set (stroker,
FT_Glyph_Stroke (&borderimg, stroker, 1);

if (borderimg->format != ft_glyph_format_bitmap)
    err = FT_Glyph_To_Bitmap (&borderimg, ft_render_mode_normal, 0, 1);
    if (err)
        gdCacheDelete (tc_cache);
        gdMutexUnlock (gdFontCacheMutex);
        return "Problem rendering glyph";
bm = (FT_BitmapGlyph) borderimg;
gdft_draw_bitmap (tc_cache, im, 2, bm->bitmap,
                  x + (penf.x * cos_a + penf.y * sin_a)*hdpi/(METRIC_RES*64) +
                  y - (penf.x * sin_a - penf.y * cos_a)*vdpi/(METRIC_RES*64) -
FT_Done_Glyph (borderimg);

This code load the stroker (thick outline of the glyph) and draw it with the
color we want. In this example, it is hardcoded to second color in color index
(the third argument in gdft_draw_bitmap).

At the end, we draw the label 2 times.

comment:15 Changed 16 years ago by sdlime

It's not as good an outline as MapServer currently, but it ain't bad at all. I 
would support the changes once GD and Freetype have releases with this, but 
until then we can't yank outlining (nobody is complaining now). This can't 
happen by the 4.6 release, unless there's some conditional compilation added.

Have you contacted John Ellson who handles the Freetype support for GD?

Great fix though. I wonder what other effects this brings into play?


comment:16 Changed 16 years ago by dmorissette

Cc: warmerdam@… added
Milestone: 4.6 releaseFUTURE
I agree that we should wait until Freetype and GD have been released with the
required functions.

I tried to find infos about the planned date for the release of Freetype 2.1.10
and found the following post saying that it was planned for end of December
But then they had some server problems in January which may have caused some
delays... the new lists are at
but I am unable to connect to the list server to subscribe and ask for an ETA,
so I give up.. they will release at some point I'm sure.

We'll also need to submit a patch to GD. I looked at this with Julien and it
should be possible to send a patch that integrates in the exsiting
gdImageStringFTEx() by passing the outline args via the gdFTStringExtra struct.
Julien will attach a patch to this bug and then we'll try to submit it to GD.

Frank, Steve, did you guys not have a support agreement with Would
it be easier to submit the patch through you?

comment:17 Changed 16 years ago by fwarmerdam

The support agreement has expired now.  It was just a one year thing. 

Changed 16 years ago by jlacroix

Attachment: mapgd.patch added

patch to use freetype oulines

Changed 16 years ago by jlacroix

Attachment: gd.h.patch added

patch gd.h to use freetype outline

Changed 16 years ago by jlacroix

Attachment: gdft.c.patch added

patch gdft.c to use freetype outline

comment:18 Changed 16 years ago by jlacroix

Status: assignednew
I atached the patch to use this technology. Feel free to test/use it. It require
at least 
freetype from september 2004
mapserver 4.5

The patch was built for GD on gd 2.0.33
and for mapserver with the 4.5 version as of 2005-05-06

comment:19 Changed 12 years ago by aboudreault

Pierre, a libgd maintainer, has confirmed that a similar patch will be in GD 2.1.0. He has already investigated in that patch.

comment:20 Changed 12 years ago by aboudreault

Cc: aboudreault added

comment:21 Changed 12 years ago by tbonfort

Cc: tbonfort added
Description: modified (diff)

For "historical" reasons, the AGG code uses the same behavior for 1-pixel outlines. This should probably be changed too for consistency and performance.

comment:22 Changed 12 years ago by tbonfort

AGG change committed in r8766. I'm seeing a couple of percent performance increase for heavily labelled maps.

comment:23 Changed 12 years ago by dmorissette

Milestone: FUTURE6.0 release

comment:24 Changed 12 years ago by jmckenna

Cc: jmckenna added
Note: See TracTickets for help on using tickets.