Re: Quartz/memory benchmarks...
Re: Quartz/memory benchmarks...
- Subject: Re: Quartz/memory benchmarks...
- From: Paul Fox <email@hidden>
- Date: Fri, 28 Jun 2002 23:33:07 +0100
>
On torsdag, juni 27, 2002, at 11:22 , Paul Fox wrote:
>
>
> My initial results show that string drawing is a killer [...]
>
>
>
> This is using [NSString drawAt:]. I have experimented with directly
>
> calling the NSLayoutManager and as yet I am 25% slower than NSString, so
>
> I am missing some optimisations.
>
>
I also found string drawing rather slow and so switched to
>
CGContextShowGlyphs(), which is faster.
>
>
Unfortunately I have to provide glyphs rather than strings, and CGGlyph
>
(as the function expect) is not the same as an NSGlyph, so you can't
>
just typecast the result from e.g. NSLayoutManager...
>
>
And resorting to using the Core Graphics is rather irritating when one
>
wants to use Cocoa -- not to mention that using the more low-level API
>
is often not enough to speed up things...
Well I used CGContextShowTextAtPoint (or whatever its called) is about
10x faster than the cocoa stuff! Alas, that 10x perf increase slows down
dramatically as I set the CG context attributes to make the two
bits of code equivalent (font, CTM, etc).
This would almost be a winner - except the flipping CG library is deficient.
If you look at the API calls - all nice looking til you try to actually
create a CG (CGContextCreateBitmap or whatever its called comes
close but its a dead end - doesnt draw anywhere). So you
have to use the CGContextRef from [NSApp] but that means you
cannot cache CG attributes which results in the slow down.
Whoever originally designed those APIs needs to learn how to program,
and make available the missing pieces of the puzzle.
I havent tried the CGContextShowGlyphs() call but I fear that leads
to the same dead end.
>
> I think Apple should carry on with Cocoa and provide a complete new
>
> API with none of the anti-aliasing, floating-point co-ords crap and
>
>
I wouldn't really go that far... anti-alias is a must today, and I'm not
>
sure foating point itself slows it down. At least for x86 processors I'm
>
told they handle floats faster than integers.
I dislike anti-alias on my screen (on some screens, maybe CRTs, it may
look better). Floats may be processed faster than int's for some
types of code but I suspect in general they are slower than int's as
most of the instruction set will be for int's, and only a smaller
set for floats. On the x86 float maths can be very fast but the
compiler optimisations will be geared to int's. Its difficult to
quantify this one way or the other without writing non-real-code
(I'm thinking of things like passing freg's to functions, return results,
typical if-then-else and switch code).
But with floats, doing "if (a == b)" is fraught with disaster and I
suspect low down those floats get converted to int's to map to real pixels.
>
Btw: you can actually disable anti-alias by calling setShouldAntiAlias
>
on your current NSGraphicsContext. Though i don't know if it provides a
>
speed-up.
Yes - it provides a 50% speed up.
Now what is interesting is I stumbled into the setNeedsDisplay and
setNeedsDisplayIfNeeded bug. I am blowed away at how bad it is.
Any call to either of these functions causes the drawRect: of all
parent views to be called, so a simple 'move-the-cursor to the next row'
piece of drawing causes frantic amounts of redrawing.
I am just cutting out that piece of rubbish and replacing with my
own display schedular and performance is much more acceptable, even
given the slow string drawing code.
The more I do, the more I replace of the AppKit, and the happier I am -
not being at the folly of the Apple programmers. Maybe this is wrong, but
I want performance more so than my customers will want it, and I cannot wait
1 month to see if Apple got it right (oh - and pay for the priviledge),
and another year to fix the bugs in 10.2 which are yet to be discovered.
If anyone wants to see my crappy simple app for toying with this stuff
(its hopefully educational to newbies, if nothing else), then I
can gladly post it somewhere.
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.