You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
翻 of NotoSansCJKjp-Regular: Made of ~100 beziers, which is currently too many. Maximum is floor( ((bezier atlas width)-2) / 3 ) (currently 84) because all the beziers for one glyph must be in one row of the atlas. This can be solved by using a one dimensional buffer (e.g. Buffer Texture backed by a Shader Storage Buffer Object) instead of a 2D texture acting as a data buffer for the bezier atlas. [Fixed in 6aa072d by using buffer textures which removes this 84-beziers limit.] [This glyph still doesn't render completely right due to detail density, but that's covered in another bullet below].
Any character in a font which uses cubic beziers. (A known offender is NotoSansCJKjp-Regular.) The algorithm as-is cannot handle cubic beziers, and although it could be made to handle them, it would require finding 3rd order polynomial roots in the fragment shader. So probably a better solution is to convert the cubics to quadratics up to some resolution limit before generating the atlases. [Fixed in 4cc6d9f by converting cubics to quadratics during the outline decompose phase.]
ç, Ç of LiberationSans-Regular: The intersection between the c and the ¸ renders corrupted. Not yet sure why. Based on how the corruption looks, I suspect it's related to the cell midpoint-inside detection algorithm (GridGlyph.cppfind_cells_mids_inside()).
Any glyph which requires over 254 beziers. Any of a glyph's beziers must be able to be referenced by one byte in the grid atlas, minus two values for storing metadata. I have yet to see any glyph even coming close to 254 beziers, so I don't think this a big problem. Could solve by splitting up single glyphs into multiple rendered glyphs, e.g. 4 quadrants each getting ~1/4th the beziers (might have some overlap).
Any glyph which is too dense in detail and has regions which break the "4 beziers per grid cell" limit at the current fixed grid size of 20x20. Examples: 翻. Making the grid size larger fixes this problem for most glyphs, but increases memory usage for the glyphs that do not need it. Also, at large grid sizes, glyph rendering breaks down for unknown reasons (all characters, not just this one). One solution would be a variable sized grids (perhaps packed into one atlas or separated into multiple based on grid size). Will Dobbie's original solution was to have two grids, a 2nd as an "extra" which means up to 8 beziers are allowed per grid cell. This might be able to be generalized to any number of grids per glyph, adding more as needed (e.g. using 3D textures).
(To be continued as more are discovered.)
The text was updated successfully, but these errors were encountered:
翻
ofNotoSansCJKjp-Regular
:Made of ~100 beziers, which is currently too many. Maximum is[Fixed in 6aa072d by using buffer textures which removes this 84-beziers limit.] [This glyph still doesn't render completely right due to detail density, but that's covered in another bullet below].floor( ((bezier atlas width)-2) / 3 )
(currently 84) because all the beziers for one glyph must be in one row of the atlas. This can be solved by using a one dimensional buffer (e.g. Buffer Texture backed by a Shader Storage Buffer Object) instead of a 2D texture acting as a data buffer for the bezier atlas.Any character in a font which uses cubic beziers. (A known offender is[Fixed in 4cc6d9f by converting cubics to quadratics during the outline decompose phase.]NotoSansCJKjp-Regular
.) The algorithm as-is cannot handle cubic beziers, and although it could be made to handle them, it would require finding 3rd order polynomial roots in the fragment shader. So probably a better solution is to convert the cubics to quadratics up to some resolution limit before generating the atlases.ç
,Ç
ofLiberationSans-Regular
: The intersection between thec
and the¸
renders corrupted. Not yet sure why. Based on how the corruption looks, I suspect it's related to the cell midpoint-inside detection algorithm (GridGlyph.cpp
find_cells_mids_inside()
).Any glyph which requires over 254 beziers. Any of a glyph's beziers must be able to be referenced by one byte in the grid atlas, minus two values for storing metadata. I have yet to see any glyph even coming close to 254 beziers, so I don't think this a big problem. Could solve by splitting up single glyphs into multiple rendered glyphs, e.g. 4 quadrants each getting ~1/4th the beziers (might have some overlap).
Any glyph which is too dense in detail and has regions which break the "4 beziers per grid cell" limit at the current fixed grid size of 20x20. Examples:
翻
. Making the grid size larger fixes this problem for most glyphs, but increases memory usage for the glyphs that do not need it. Also, at large grid sizes, glyph rendering breaks down for unknown reasons (all characters, not just this one). One solution would be a variable sized grids (perhaps packed into one atlas or separated into multiple based on grid size). Will Dobbie's original solution was to have two grids, a 2nd as an "extra" which means up to 8 beziers are allowed per grid cell. This might be able to be generalized to any number of grids per glyph, adding more as needed (e.g. using 3D textures).(To be continued as more are discovered.)
The text was updated successfully, but these errors were encountered: