1

我正在尝试制作一个GlyphRun实例以在GlyphRunDrawing中使用,但是文档太糟糕了,以至于几乎可笑。例如,参数renderingEmSize描述如下:

renderingEmSizeType: System.Double
A value of type Double.

只是……哇。

我知道字体中的“em”是什么(em dash 的宽度),但我不知道网格单位是什么。设备像素?设备独立像素?

4

1 回答 1

2

原来答案在源代码中。感谢 MS 提供此功能,如果他们要让文档流血的话。

有趣的是,我们需要的所有信息都包含在 xml 文档注释中GlyphRun.cs。例如renderingEmSize,如下:

<param name="renderingEmSize">Font rendering size in drawing surface units (96ths of an inch).</param>

文件的其余部分也有类似的评论,包括这个看似不合时宜但扣人心弦的读物:

/*
The default branch prediction rules for modern processors specify that forward branches
are not to be taken. If the branch is in fact taken, all of the speculatively executed code
must be discarded, the processor pipeline flushed, and then reloaded. This results in a
processor stall of at least 42 cycles for the P4 Northwood for each mis-predicted branch. 
The deeper the processor pipeline the higher the cost, i.e. Prescott processors.
Checking for multiple incorrect parameters in a method with high call count like this one can 
easily add significant overhead for no reason. Note that the C# compiler should be able to make 
reasonable assumptions about branches that throw exceptions, but the current whidbey
implemenation is weak in this regard. Also the current IBC tools are unable to add branch 
prediction hints to improve behavior based on run time information. Also note that adding
branch prediction hints increases code size by a byte per branch and doing this in every
method that is coded without default branch prediction behavior in mind would add an
unacceptable amount of working set. 
*/

整个文件可以在这里找到:GlyphRun.cs at webtropy

于 2012-12-04T01:15:23.560 回答