New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track RFC98: Text Placement Refactoring #4673

Closed
tbonfort opened this Issue Jun 26, 2013 · 4 comments

Comments

Projects
None yet
3 participants
@tbonfort
Member

tbonfort commented Jun 26, 2013

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)
  • #4408 labelpoly scalefactor

@ghost ghost assigned tbonfort Jun 26, 2013

tbonfort added a commit to mapserver/docs that referenced this issue Aug 12, 2013

tbonfort added a commit that referenced this issue Sep 23, 2013

implement RFC98 (#4673) and RFC99 (#4704)
- implement complex scrit shaping via harfbuzz
- refactor text rendering pipeline
- remove support for GD renderer
- remove support for deprecated annotation layers

tbonfort added a commit that referenced this issue Sep 25, 2013

@tbonfort tbonfort closed this Sep 2, 2014

@rbovard rbovard referenced this issue Feb 16, 2016

Closed

Blurry labels #5242

@NathanW2

This comment has been minimized.

Contributor

NathanW2 commented Nov 29, 2017

@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

This comment has been minimized.

Member

szekerest commented Nov 29, 2017

@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

This comment has been minimized.

Contributor

NathanW2 commented Nov 29, 2017

@szekerest

This comment has been minimized.

Member

szekerest commented Nov 29, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment