schell / odin

High level 2d game engine written in Haskell.
http://zyghost.com/series/odin
MIT License
31 stars 4 forks source link

Create a text layout mechanism for interacting with large-ish bodies of text. #3

Closed schell closed 8 years ago

schell commented 8 years ago

When working with larger bodies of text (like > 4 words), measuring the bounds of text gets really expensive. You can see here how slow the prog gets while editing text.

thu-aug-18-09-57-01-pdt-2016

I think I could write a layout "engine" that only re-renders and re-measures each new word, and saves each processed word in a map keyed by the word itself.

Attached are the prof and ps files from a similar run.

Thu-Aug-18-09:48:52-PDT-2016 copy.txt Thu-Aug-18-09:48:52-PDT-2016 copy.pdf

schell commented 8 years ago

@Peaker - sorry to pull you in on my project, but you probably have experience with rendering lots of text with lamdu. Have you run into this problem before? What are you using to render and layout text in lamdu?

schell commented 8 years ago

A little more spelunking and it looks like it's FTGL via graphics-drawingcombinators, added in https://github.com/lamdu/lamdu/commit/f9aa3a403aacfad9c967cec945662ad576cf0b78

Peaker commented 8 years ago

Font rendering was far harder than I anticipated.

Text has no width, really, but a bounding box and an "advance".

We switched from FTGL which doesn't have subpixel rendering to freetype-gl with some minor modifications, that does. It's also a c codebase around libfreetype so easier to compile everywhere.

It does the width computations for us and I've not noticed slowness of text geometry computations, but I've not done extensive profiling either.

schell commented 8 years ago

Thanks for that, I'm checking out freetype-gl now, which may make this ticket moot.

Sent from my iPhone

On Aug 18, 2016, at 11:15 AM, Eyal Lotem notifications@github.com wrote:

Font rendering was far harder than I anticipated.

Text has no width, really, but a bounding box and an "advance".

We switched from FTGL which doesn't have subpixel rendering to freetype-gl with some minor modifications, that does. It's also a c codebase around libfreetype so easier to compile everywhere.

It does the width computations for us and I've not noticed slowness of text geometry computations, but I've not done extensive profiling either.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.