here's what I think is a better version of the start of the
function. [...]
This is now in the git repository (with small fixes to make it
compile).
Thanks a lot! Please test.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
You're welcome - I see that you had to get rid of a check on the return
value of gray_render_line, which I forgot about. That is there because I
use a modified version of FreeType that can be compiled as pure .NET
intermediate language code; and to do that I had to get rid of setjmp
and
[...] I use a modified version of FreeType that can be compiled as
pure .NET intermediate language code; and to do that I had to get
rid of setjmp and longjmp; incidentally, with no performance penalty
and little extra complexity.
Is this something we should consider in general? I mean, are
No, I don't think it's worth worrying about this right now. I worked on
this because I wanted to create a version of my CartoType library as a
portable .NET assembly, and in fact I managed to compile CartoType as
C++/CLI code, which is a tribute to its robustness; but to do that I had
to
On 06/10/2010 05:17 AM, Graham Asher wrote:
Doing this showed that setjmp and longjmp are not necessary for
FreeType;
Indeed. They are only used for error-handling in the validator modules.
behdad
___
Freetype-devel mailing list
On 06/10/2010 05:17 AM, Graham Asher wrote:
Doing this showed that setjmp and longjmp are not necessary for
FreeType;
Indeed. They are only used for error-handling in the validator modules.
behdad
___
Freetype-devel mailing list
Unfortunately not only there but in the rasterizer, if memory serves.
They were not in any place where I could get rid of them easily by
disabling certain features.
Graham
Behdad Esfahbod wrote:
On 06/10/2010 05:17 AM, Graham Asher wrote:
Doing this showed that setjmp and longjmp are
This is something Ken can probably check: He has a large database
for Ghostscript to compare rendering results, and artifacts
introduced by the simplified shorthand calculation would easily show
up, I think.
I'd like to be able to, but at the moment GS doesn't use FreeType
for anti-aliased
Calculate the midpoint and compare it with start and end: [...]
For me, this looks good. Thanks for working on this.
I am sceptical about the need to calculate both da and db. Perhaps
db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably check:
At 10:04 08/06/2010 +0200, Werner LEMBERG wrote:
I am sceptical about the need to calculate both da and db. Perhaps
db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably check: He has a large database for
Ghostscript to compare rendering results,
Werner,
I think your patch is slightly wrong because you use the same values for
mid_x and mid_y for both the comparison and for drawing; however, one
set if values needs to go through DownScale() and the other through
UpScale(); that's why I calculate separately in my hastily-prepared
Another question arises: why do we divide by ras.conic_level when we are
dealing with cubic splines? Surely it should be
dx= dx / ras.cubic_level;
or (better - we can use assignment operators in FreeType, I think ;-):
dx/= ras.cubic_level;
Graham
Werner LEMBERG wrote:
Calculate
Werner,
here's what I think is a better version of the start of the function.
I've combined a few declarations and initialisations; probably against
your house style, so please adjust as appropriate if you don't like it.
Important changes: (i) dx is now divided by ras.cubic_level; (ii) mid_x
13 matches
Mail list logo
