Re: Quickly drawing non-antialiased, discrete, pixels
Re: Quickly drawing non-antialiased, discrete, pixels
- Subject: Re: Quickly drawing non-antialiased, discrete, pixels
- From: Roarke Lynch <email@hidden>
- Date: Sat, 4 Jan 2003 10:27:12 -0500
I was doing something like this really quickly just a few days ago. It
ended up running fast enough for me, but I wasn't overly concerned with
perfomance. I subclassed my NSView, in its awakeFromNib, I generated an
NSBitmapImageRep, and added it to an NSImage, both were members of
myNSView, as well as the data planes used to generate the NSBIR. All
that drawRect did was [myImage compositeToPoint:NSMakePoint(0,0)
operation:NSCompositeCopy]. My pixel manipulation process was fired on
a NSTimer w/ time interval at 0.0, and it manipulated the dataPlanes
directly, and than called [self setNeedsDisplay:YES]. There is probably
a more elegant solution, perhaps involving NSImageView.
On Saturday, January 4, 2003, at 09:19 AM, Bill Bumgarner wrote:
This has probably been discussed in the archives, but I don't have
access to the archives and the next time I do, I will no longer be
vacating and, as such, this entire hack will have to be pushed out of
context...
Quick question: How does one quickly draw lots and lots of discrete,
non-contiguous, pixels into an NSView that is not anti-aliased?
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.
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. 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. 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.
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.
On the PyObjC front, it is now possible to instantiate an
NSBitmapImageRep and then grab and manipulate the bitmap memory
directly via -getBitmapDataPlanes. Python Imaging Library [PIL]
integration should now be trivial.
Whatever I discover will be turned into an open source example...
Thanks,
b.bum
Roarke Lynch
-------------------------------
email@hidden
_______________________________________________
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.