Track RFC98: Text Placement Refactoring

[tbonfort]

Track RFC98 implementation

• remove GD support (RFC99)
• remove ANNOTATION layers
• implement a global freetype glyph/font cache
• agg and cairo renderer glyph handling rewrite
• truetype symbol marker placements
• truetype line markers (gap != 0)
• baseline adjustments
• iconv/bidi
• harfbuzz shaping
• labelcache speedups
• leader labels
• text alignment
• bitmap labels
• non labelcache'd layers (kml)
• label annopoly may use wrong scalefactor #4408 labelpoly scalefactor

[NathanW2]

@tbonfort I was just wondering for this item "implement a global freetype glyph/font cache" does that mean that there should be a single global font cache for all threads? Seems the code only uses it if not using USE_THREAD. Is each thread meant to have a copy of the font cache in this instance?

[szekerest]

@NathanW2 I assume this has been implemented to avoid the cost of thread locking in exchange for the cost of duplicating the cache elements (for the same file). It may also be OS dependent that keeping the file open or limit the lifetime of the open handles would be more sufficient. I think on a production server with high load (ie. high number of threads in a process and high number of drawing sessions per second) limiting the lifetime of the open handles would be more scalable.

[NathanW2]

The locking be from the cache being read/write vs just read right?

…

On Wed, Nov 29, 2017 at 9:55 PM, Tamas Szekeres ***@***.***> wrote: @NathanW2 <https://github.com/nathanw2> I assume this has been implemented to avoid the cost of thread locking in exchange for the cost of duplicating the cache elements (for the same file). It may also be OS dependent that keeping the file open or limit the lifetime of the open handles would be more sufficient. I think on a production server with high load (ie. high number of thread in a process and high number of drawing sessions per second) limiting the lifetime of the open handles would be more scalable. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4673 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXS3GGkN4sshkHecU3bXIFjE3KjjI8Mks5s7UZGgaJpZM4AxI2d> .

[szekerest]

Not sure what you mean, we might either read or write the cache structure in a single operation.