Re: Quickly drawing non-antialiased, discrete, pixels
Re: Quickly drawing non-antialiased, discrete, pixels
- Subject: Re: Quickly drawing non-antialiased, discrete, pixels
- From: Marcel Weiher <email@hidden>
- Date: Mon, 6 Jan 2003 13:26:13 +0100
A frame could be considered a single point-- if I don't do any
drawing, the code produces about 100,000 points in less than 15
seconds on a TiBook 667. Initially, I defined a 'frame' as a color
transition with a 1,000 palette; this yielded 100 'frames' in 15
seconds-- assuming no drawing.
I have sense moved to using perform:afterDelay: with an initial delay
of 0.5 seconds to get something on the screen quickly and 3 second
intervals for updating after that.
Updates every 3 seconds? That should be barely perceptible and hardly
measurable. Are you sure there aren't other factors affecting this?
Hmm, that might run afoul NSBezierPath's "lots of combined paths"
performance bug. I think it does the self-intersection tests even
when you're not asking for anti-aliasing. Have you tried one of the
rect-fill functions instead? NSRectFillList( const NSRect *rects,
int count); springs to mind.
For a rect that represents a single point at 100,100, would I use
((100,100), (1,1)) or ((99.5,99.5), (1,1)) or something else?
I am not 100% sure. Normal NSBezierPath usage would suggest ( 99.5,
99.5 ), but I don't know if they don't handle (filled) rectangles
specially. Also, there is a (private) CG-function that enables
automatic stroke-adjust.
Also, a very simple way to speed up drawing would be to split up your
large NSBezierPath into individual ones, one for each point.
Actually, you are always getting resampling with NSBitmapImagRep
because none the native byte-orders ( ARGB for both 32 (8/8/8/8) and
16 bit ( 1/5/5/5) depths) are supported NSBItmapImageRep layouts (
RGBA for 32 and 16 ( 4/4/4/4 ) bit depths). So for better
performance, you need to drop down to CoreGraphics.
Oh-- interesting and truly unfortunate. That sounds like a bug to be
filed-- hopefully, it has already been filed n times over. The
AppKit's image classes should definitely support the native byte
ordering of the underlying blit'ing layer.
Yup.
In any case, I'm actually using simply RGB w/no alpha channel. It
takes 20 seconds to render 100,000 points with 2 second update
intervals.
Is that total time including the 15 seconds to calculate the points?
That would mean (20/2) 10 updates in (20-15) 5 seconds, meaning 1/2
second per compositing operation, which seems wrong. Are you sure you
are only rendering every 2 seconds?
Would it be possible to push a custom color space into the image rep
that represents ARGB data (and gain any performance that way)?
I don't think this is possible, and it would almost certainly involve
CG-functions, so you might as well just use the CG image-drawing
operations.
Some more context: This entire exercise is being done in PyObjC
while I'm on vacation (this is vacating for me :-). A friend of
mine and I were having a discussion comparing PyObjC, Cocoa, wx*,
wxPython, and other 'high level' GUI development environments. At
random, he tossed a draw-a-bunch-of-discrete-points-on-screen
example my direction that used PythonCard (wxPython) and I ported it
to PyObjC. The drawing performance is abysmal and it isn't because
of the Python VM. It is most likely because of my ignorance.
Or even more likely because of Quartz...
Yes. It strikes me that there are a number of fairly major
opportunities for optimization within Quartz.
And for better integration. For example, there is still no API for
taking a CG-context and turning it into a NSGraphicContext (or
attaching it).
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
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.