On Jun 23, 2007, at 7:42 PM, imm wrote:
> Matthias, you said before that there was still some QD stuff to be
> sorted out to make the Quartz port "complete" - and suggested that
> might
> be impacting performance a bit...
Quartz is the graphics library for Cocoa, QD is the graphics library
for Carbon. I had no time (or knowledge) to convert the window and
message system from Carbon to Cocoa yet, so in order to get Quartz
running in a Carbon window, I have to use a call that is fully
supported, but still has a hackish smell. We are wasting cycles
setting up a Carbon window using a Carbon emulator on top of Cocoa,
only to then retrieve a Quartz graphics surface, which Cocoa would
have given us without any emulations.
This needs to be sorted out, but I am currently stuck inside another
project.
> I've been using the Quartz port a fair bit for my UTF8 stuff and (at
> least on my fairly old dual-G4) box it does seem slower.
> So... it's fairly likely that the slowness comes from my ATSU font
> handling mods, but if there is scope for enhancement elsewhere, I
> might
> give it a shot.
The ATSU font stuff does so much more than FLTK1 can handle. This
makes font rendering beautiful (sub-pixel positioning, full
antialiasing, variable kerning), but nevertheless I had to disable at
least the subpixel positioning because FLTK1 does not support that.
But all those features make rendering incredibly slow, and even just
calling fl_length("hello") takes magnitudes longer than on other
platforms, so I had to disable variable kerning as well.
Still, measuring a string was too slow, so I ended up calculating
character widths once, assuming fixed kerning, and storing all in a
fixed array. But that is not possible with UTF8 because there are so
many more characters. We will have to do some kind of hashing here,
or live with the slow implementation of ATSU, especially since I
really would love to reactivate the features mentioned above. It
looks just so much better.
> Anyway, where do I look? Can you give me some pointers for what's
> what,
> what needs doing, etc.? That said, I don't imagine I'll be able to fix
> it, but I can always look!
I have not looked at the UTF8 stuff yet, s I don't really know where
to start either. I do remember that "test/editor" was excruciatingly
slow on my G4, but introducing the width table fixed that issue.
Matthias
----
http://robowerk.com/
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
