freenode/#shirakumo - IRC Chatlog
Search
22:29:03
mfiano
I should be able to look at the filter method of all rows first, and then process the ones with the None or Sub filters first in parallel (the ones where pixels are unmodified or depend on the left pixel). Then the sparse rows can be processed diagonally
23:34:13
|3b|
Shinmera: yeah, map-glyphs was as a minimal "get something working" api, and real layout should probably be a separate lib. no idea what APIs would be useful for that beyond just the raw data without writing it though :)
23:34:55
|3b|
mfiano: threading pngload doesn't seem too useful to me, i'd probably just do SSE stuff and thread at whole-image level
6:09:43
Shinmera
|3b|: Pretty sure it'd just need fast access to glyph, kerning, and ligature lookup.
6:13:03
|3b|
yeah, i guess it sort of depends on whether there are going to be more font metadata libs or more text layout libs when trying to decide where things belong from perspective of avoiding code duplication :p
6:13:40
Shinmera
I'm assuming the former since a glyph renderer is likely going to need additional info as well.
6:15:21
|3b|
seems like at this point, mostly just "some simple bitmap font atlas" and "some variant of ttf"
6:16:37
Shinmera
My point is more that a glyph renderer is also gonna be parsing the metrics to do a demo, just like you did.
6:17:20
Shinmera
In our specific case we're even loading from a cached file we ultimately have no control over.
6:17:25
|3b|
unrelated, trying to figure out if things look right, when 'right' looks wrong, is hard :p
6:20:30
|3b|
so the lines are supposed to be rectangular in screen space, which doesn't match the world-space 3d transforms
6:20:40
Shinmera
Well, I suppose here's where one of those problems comes in, namely that now your lines are "3D" rather than always facing the camera and thus completely flat.