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: Sun, 5 Jan 2003 18:58:45 +0100
On Saturday, January 4, 2003, at 03:19 Uhr, Bill Bumgarner wrote:
Quick question: How does one quickly draw lots and lots of discrete,
non-contiguous, pixels into an NSView that is not anti-aliased?
Maybe with an image-mask? Sadly, there is no Cocoa class for this, so
you would have to drop down to CG.
I'm running an algorithm that produces several hundreds of thousand
points. The points are divided into sets by color-- i.e. if I define
a color palette of 1000 colors, then I will get N-hundred consecutive
points of the first color, N-hundred consecutive points of the second
color, etc..
I'm using the color change as an 'end frame' marker. That is, after
each color change, I plot the all points in the previously produced
color.
How quickly are "frames" produced? Might it be better to simply mark
the image as needing display and only updating a fixed number of times?
NSBezierPath does not seem to be the right way to go as NSBP does not
perpetuate the concept of a 1x1 pixel -- a point in NSBP is truly a
point; a single location with zero width/height. And it is slow--
not slow for what it is doing, but very slow for doing something
similar like trying to set the color of an individual pixel within an
NSView. (Actually, I was slapping each color's set of points into an
NSBP instance and rendering each path into an NSImage.
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.
The NSImage would accumulate the rendered NSBPs and the image was
then composited into the view as needed.)
NSBitmapImageRep works-- I tried accumulating the points/colors in a
single NSBIR instance and slapping it on screen in the View's
drawSelf:-- but is even slower than NSBP. I'm using a 24bit deep
image on a 'millions of colors' screen, so the to-screen resampling
should be minimal and it is still about 4 times slower than drawing
the same image with NSBP.
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.
Compositing the whole image for each point plotted, or after each color
change? Are the plotted points geometrically close? Clipping to
just the affected region helps if it is significantly smaller than the
whole image.
Of course, if I change the code to not update the screen after each
color change-- just update after all 100,000+ points are calculated--
then this method is considerably faster than NSBP.
;-)
What are my alternatives from here? I would like to avoid OpenGL, if
possible.
Alas, OpenGL seems to be the (only) way to go if you want really great
performance.
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...
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.