1

GlyphRunDrawingで使用するGlyphRunインスタンスを作成しようとしていますが、ドキュメントが非常に悪いため、ほとんどコミカルです。たとえば、パラメータは次のように記述されます。renderingEmSize

renderingEmSizeType: System.Double
A value of type Double.

ただ...すごい。

フォントの「em」（emダッシュの幅）はわかりますが、グリッド単位が何であるかはわかりません。デバイスのピクセル？デバイスに依存しないピクセル？

4

1 に答える 1

2

答えはソースコードにあることがわかりました。MSがこれを利用できるようにしてくれてありがとう、もし彼らがドキュメントに目を出血させようとしているのなら。

興味深いことに、必要なすべての情報は、のxmldocコメントに含まれてい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. 
*/

ファイル全体はここにあります：webtropyのGlyphRun.cs

于 2012-12-04T01:15:23.560 に答える