Closed EranBoudjnah closed 11 years ago
Yes. It turns out that sizeWithFont rounds up to the nearest whole point, which makes the calculations totally wrong when I'm drawing everything character-by-character (it wasn't an issue previously when I was drawing a whole line of text at a time).
If you aren't using the characterSpacing feature you'd be better off using the previous stable version of FXLabel instead of the current beta version, but I'd be interested to know what warnings you are seeing?
Super fast response! I was getting countless warnings because context was not yet initialized (sorry, now that I modified the class I'm no longer getting them so can't quote them). Keep in mind you are actually drawing the text twice, which also affects quality around the edges, I'd imagine.
I'm not drawing it twice because the text drawing mode is set to kCGTextInvisible prior to drawing, but yes it is certainly non-optimal, hence the beta status.
Cool, hope I pointed out something worth considering. Maybe even consider using a font ten times larger to achieve the precision you require? Just from the top of my head. Would require benchmarking etc...
I've just updated with a fix that works by creating a new context specifically for doing the sizing logic. Can you check if the new version fixes the errors you were seeing?
Wonderful. No warnings now :) Thanks!
Hi,
Is there are reason for using drawAtPoint: withFont: instead of just sizeWithFont: in FXLabel_sizeWithFont: ?
Because the latter saves the need to use a context, prevents pointless drawing and a lot of warnings I got during run time prior to changing it. Am I missing anything?
Cheers, -Eran