invertrect, any cocoa versions suggested?
-
Since invertrect is going to be depreciated, what are my choices for doing what it does?
getcpixel and setcpixel are also depreciated and i would like to know the suggested cocoa replacements for those as well.
yes, i HAVE read the books and nothing was suggested when i searched for them... only "supported under carbonlib" and "depreciated" were the only 2 responses i got back. -
On Jan 23, 2006, at 8:05 PM, Robert Dell wrote:
> Since invertrect is going to be depreciated, what are my choices
> for doing what it does?
Do you need exactly the the look that invert rect provides, or
something equivalent? You didn't say exactly what you were doing. If
you don't really need to invert the pixels, but just provide some
sort of indicator (of selection?) there are several nicer alternatives.
Jim -
yes, i actually need to invert the color pixels within the rectangle.
if i had access to the actual pixels, i could invert them myself (although that wouldn't be the fastest way) one pixel at a time.
i also need to read and set individual pixels the same way getcpixel and setcpixel did.
Nothing i've searched on the web, apple's site, or the frameworks gives me any indication of what i'm trying to do. the closest thing i can come up with is coreimage but i'm unsure on how it works and it can't invert the color data.
implementing an apple2 hi-res graphics screen is the main thrust for this program segment. more specifically, the apple pascal's turtlegraphics routines in their entirety (other than textmode and grafmode procedures) for script programmers.
i've already implemented the following:
-(void)initGraphicWindow;
{
graphicwindow = [[NSWindow alloc] initWithContentRect: NSMakeRect(graphicwindowlocation.x, graphicwindowlocation.y, 280, 192) styleMask: (NSTitledWindowMask) backing: NSBackingStoreBuffered defer: NO];
[graphicwindow setTitle: @"Turtlegraphics"];
[graphicwindow setViewsNeedDisplay: YES];
[graphicwindow makeKeyAndOrderFront: self];
[graphicwindow display];
mycontext = [[NSGraphicsContext graphicsContextWithWindow: graphicwindow] retain];
context = (CGContextRef)[mycontext graphicsPort];
turtleAngle = 0;
[self ViewPort: NSMakeRect(0, 0, 279, 191)];
[self PenColor: YASSEWhite];
[self PenUp];
[self MoveTo: NSMakePoint(0, 0)];
[self TurnTo: 0];
[self Erase];
};
-(void)ViewPort: (NSRect)thePort;
{
NSRect myrect;
myrect = thePort;
if (myrect.origin.x < 0)
{
myrect.origin.x = 0;
};
if (myrect.origin.y < 0)
{
myrect.origin.y = 0;
};
if ((myrect.size.width + myrect.origin.x) > 279)
{
myrect.size.width = 280 - myrect.origin.x;
};
if ((myrect.size.height + myrect.origin.y) > 191)
{
myrect.size.height = 192 - myrect.origin.y;
};
turtleViewPort = myrect;
myCGRect = NSRectToCGRect(myrect);
};
-(void)FillScreen: (NSColor *)theColor;
{
if (graphicwindowvisible)
{
//[self getContextForWindow];
CGContextSetRGBFillColor(context, [theColor redComponent], [theColor greenComponent], [theColor blueComponent], 1);
CGContextBeginPath(context);
CGContextFillRect(context, myCGRect);
//CGContextClosePath(context);
CGContextFlush(context);
}
};
-(void)TurnTo: (int)angle;
{
int temp = angle;
if (temp < 0)
{
while (temp < 0)
{
temp += 360;
};
};
if (temp > 359)
{
while (temp > 359)
{
temp -= 360;
};
};
turtleAngle = temp;
};
-(void)Turn: (int)angle;
{
int temp = turtleAngle + angle;
if (temp < 0)
{
while (temp < 0)
{
temp += 360;
};
};
if (temp > 359)
{
while (temp > 359)
{
temp -= 360;
};
};
turtleAngle = temp;
};
-(void)MoveTo: (NSPoint)Position;
{
/*
if (Position.x > 279)
{
Position.x = 279;
};
if (Position.y > 191)
{
Position.y = 191;
};
if (Position.x < 0)
{
Position.x = 0;
};
if (Position.y < 0)
{
Position.y = 0;
};
*/
if (turtlePenMode)
{
// code a line here
if (graphicwindowvisible)
{
//[self getContextForWindow];
CGContextSetRGBStrokeColor(context, [penColor redComponent], [penColor greenComponent], [penColor blueComponent], 1);
CGContextSetLineWidth(context, 1);
CGContextBeginPath(context);
CGContextMoveToPoint(context, turtlePosition.x + .5, turtlePosition.y + .5);
CGContextAddLineToPoint(context, Position.x + .5, Position.y + .5);
CGContextStrokePath(context);
//CGContextClosePath(context);
CGContextFlush(context);
}
};
turtlePosition = Position;
};
-(void)Move: (int)distance;
{
NSPoint dest;
dest.y = turtlePosition.y + round(cos((turtleAngle / 360.0) * 2 * 3.14159265365) * distance); // 6.2831853017 is 2 * pi
dest.x = turtlePosition.x + round(sin((turtleAngle / 360.0) * 2 * 3.14159265365) * distance); // 6.2831853017 is 2 * pi
[self MoveTo: dest];
};
-(void)PenUp;
{
turtlePenMode = NO;
};
-(void)PenDown;
{
turtlePenMode = YES;
};
-(void)Erase;
{
NSRect tmp = turtleViewPort;
[self ViewPort: NSMakeRect(0, 0, 280, 192)];
[self FillScreen: YASSEBlack];
[self ViewPort: NSMakeRect(tmp.origin.x, tmp.origin.y, tmp.size.width, tmp.size.height)];
};
-(void)PenColor: (NSColor *) theColor;
{
penColor = [[NSColor colorWithCalibratedRed: [theColor redComponent] green: [theColor greenComponent] blue: [theColor blueComponent] alpha: 1.0] retain];
};
and a few more.
Jim Correia wrote:
> On Jan 23, 2006, at 8:05 PM, Robert Dell wrote:
>
>> Since invertrect is going to be depreciated, what are my choices for
>> doing what it does?
>
>
> Do you need exactly the the look that invert rect provides, or
> something equivalent? You didn't say exactly what you were doing. If
> you don't really need to invert the pixels, but just provide some sort
> of indicator (of selection?) there are several nicer alternatives.
>
> Jim
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<dellr...>
>
> This email sent to <dellr...>
>
-
The problem here is that Core Graphics doesn't really work in terms of
"pixels" per se. It's built around resolution-independent vector
graphics concepts. For example, you can apply a transformation matrix to
the view which will skew, rotate or scale it. So conceptually, there
really aren't any "pixels" for you to get at, unfortunately.
I don't think CG offers an "invert" fill mode either, unfortunately. I
can't see any conceptual reason why not. My only hunch is maybe that
"invert" doesn't seem very useful in a PostScript world, and
CoreGraphics is descended from Display PostScript.
Robert Dell wrote:
> yes, i actually need to invert the color pixels within the rectangle.
> if i had access to the actual pixels, i could invert them myself
> (although that wouldn't be the fastest way) one pixel at a time.
>
> i also need to read and set individual pixels the same way getcpixel
> and setcpixel did.
>
> Nothing i've searched on the web, apple's site, or the frameworks
> gives me any indication of what i'm trying to do. the closest thing i
> can come up with is coreimage but i'm unsure on how it works and it
> can't invert the color data.
>
> implementing an apple2 hi-res graphics screen is the main thrust for
> this program segment. more specifically, the apple pascal's
> turtlegraphics routines in their entirety (other than textmode and
> grafmode procedures) for script programmers.
>
> i've already implemented the following:
>
> -(void)initGraphicWindow;
> {
> graphicwindow = [[NSWindow alloc] initWithContentRect:
> NSMakeRect(graphicwindowlocation.x, graphicwindowlocation.y, 280,
> 192) styleMask: (NSTitledWindowMask) backing: NSBackingStoreBuffered
> defer: NO];
> [graphicwindow setTitle: @"Turtlegraphics"];
> [graphicwindow setViewsNeedDisplay: YES];
> [graphicwindow makeKeyAndOrderFront: self];
> [graphicwindow display];
> mycontext = [[NSGraphicsContext graphicsContextWithWindow:
> graphicwindow] retain];
> context = (CGContextRef)[mycontext graphicsPort];
> turtleAngle = 0;
> [self ViewPort: NSMakeRect(0, 0, 279, 191)];
> [self PenColor: YASSEWhite];
> [self PenUp];
> [self MoveTo: NSMakePoint(0, 0)];
> [self TurnTo: 0];
> [self Erase];
> };
>
>
> -(void)ViewPort: (NSRect)thePort;
> {
> NSRect myrect;
> myrect = thePort;
> if (myrect.origin.x < 0)
> {
> myrect.origin.x = 0;
> };
> if (myrect.origin.y < 0)
> {
> myrect.origin.y = 0;
> };
> if ((myrect.size.width + myrect.origin.x) > 279)
> {
> myrect.size.width = 280 - myrect.origin.x;
> };
> if ((myrect.size.height + myrect.origin.y) > 191)
> {
> myrect.size.height = 192 - myrect.origin.y;
> };
> turtleViewPort = myrect;
> myCGRect = NSRectToCGRect(myrect);
> };
>
> -(void)FillScreen: (NSColor *)theColor;
> {
> if (graphicwindowvisible)
> {
> //[self getContextForWindow];
> CGContextSetRGBFillColor(context, [theColor redComponent],
> [theColor greenComponent], [theColor blueComponent], 1);
> CGContextBeginPath(context);
> CGContextFillRect(context, myCGRect);
> //CGContextClosePath(context);
> CGContextFlush(context);
> }
> };
>
> -(void)TurnTo: (int)angle;
> {
> int temp = angle;
> if (temp < 0)
> {
> while (temp < 0)
> {
> temp += 360;
> };
> };
> if (temp > 359)
> {
> while (temp > 359)
> {
> temp -= 360;
> };
> };
> turtleAngle = temp;
> };
>
> -(void)Turn: (int)angle;
> {
> int temp = turtleAngle + angle;
> if (temp < 0)
> {
> while (temp < 0)
> {
> temp += 360;
> };
> };
> if (temp > 359)
> {
> while (temp > 359)
> {
> temp -= 360;
> };
> };
> turtleAngle = temp;
> };
>
> -(void)MoveTo: (NSPoint)Position;
> {
> /*
> if (Position.x > 279)
> {
> Position.x = 279;
> };
> if (Position.y > 191)
> {
> Position.y = 191;
> };
> if (Position.x < 0)
> {
> Position.x = 0;
> };
> if (Position.y < 0)
> {
> Position.y = 0;
> };
> */
> if (turtlePenMode)
> {
> // code a line here
> if (graphicwindowvisible)
> {
> //[self getContextForWindow];
> CGContextSetRGBStrokeColor(context, [penColor redComponent],
> [penColor greenComponent], [penColor blueComponent], 1);
> CGContextSetLineWidth(context, 1);
> CGContextBeginPath(context);
> CGContextMoveToPoint(context, turtlePosition.x + .5,
> turtlePosition.y + .5);
> CGContextAddLineToPoint(context, Position.x + .5, Position.y + .5);
> CGContextStrokePath(context);
> //CGContextClosePath(context);
> CGContextFlush(context);
> }
> };
> turtlePosition = Position;
> };
>
> -(void)Move: (int)distance;
> {
> NSPoint dest;
> dest.y = turtlePosition.y + round(cos((turtleAngle / 360.0) * 2 *
> 3.14159265365) * distance); // 6.2831853017 is 2 * pi
> dest.x = turtlePosition.x + round(sin((turtleAngle / 360.0) * 2 *
> 3.14159265365) * distance); // 6.2831853017 is 2 * pi
> [self MoveTo: dest];
> };
>
> -(void)PenUp;
> {
> turtlePenMode = NO;
> };
>
> -(void)PenDown;
> {
> turtlePenMode = YES;
> };
>
> -(void)Erase;
> {
> NSRect tmp = turtleViewPort;
> [self ViewPort: NSMakeRect(0, 0, 280, 192)];
> [self FillScreen: YASSEBlack];
> [self ViewPort: NSMakeRect(tmp.origin.x, tmp.origin.y,
> tmp.size.width, tmp.size.height)];
> };
>
> -(void)PenColor: (NSColor *) theColor;
> {
> penColor = [[NSColor colorWithCalibratedRed: [theColor redComponent]
> green: [theColor greenComponent] blue: [theColor blueComponent] alpha:
> 1.0] retain];
> };
>
>
> and a few more.
>
>
>
> Jim Correia wrote:
>> On Jan 23, 2006, at 8:05 PM, Robert Dell wrote:
>>
>>> Since invertrect is going to be depreciated, what are my choices
>>> for doing what it does?
>>
>>
>> Do you need exactly the the look that invert rect provides, or
>> something equivalent? You didn't say exactly what you were doing. If
>> you don't really need to invert the pixels, but just provide some
>> sort of indicator (of selection?) there are several nicer alternatives.
>>
>> Jim
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (<Cocoa-dev...>)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/<dellr...>
>>
>> This email sent to <dellr...>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<jstiles...>
>
> This email sent to <jstiles...>
-
On Jan 23, 2006, at 11:01 PM, Robert Dell wrote:
> yes, i actually need to invert the color pixels within the rectangle.
> if i had access to the actual pixels, i could invert them myself
> (although that wouldn't be the fastest way) one pixel at a time.
>
> i also need to read and set individual pixels the same way
> getcpixel and setcpixel did.
>
well, reading is doable with NSReadPixel (http://developer.apple.com/
documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Functions/
AppKitFunctions.html) (I'd be very surprised if there aren't direct
replaces in the CoreGraphics for the two old functions)
but that requires that the drawing be contained in a focus capable
view/bitmap image (which is easy to do mind you), and if that is a
requirement for using it, there there are other options available.
you can directly access the memory used by the NSBitmapImageRep that
an NSImage contains.
However.. MOST IMPORTANTLY...
CoreImage can most certainly accomplish this for you far faster
than using read/write pixel functions. In fact, the
CoreImageFunHouse example installed with the developer tools can do
it (including color invert). Grab a bitmap of the area of the view
you're drawing into, and transform it using CI. It really is trivial
this way -
On Monday, January 23, 2006, at 10:42PM, Robert Dell <dellr...> wrote:
> yes, i actually need to invert the color pixels within the rectangle.
> if i had access to the actual pixels, i could invert them myself (although that wouldn't be the fastest way) one pixel at a time.
Just what kind of speed do you need? I use direct pixel access of an NSBitmapImageRep and perform convert-to-grayscale (NTSC weighted algorithm) of 1024x768 images. On a dual 2GHz G5, it's only a few microseconds.
> i also need to read and set individual pixels the same way getcpixel and setcpixel did.
Those two routines were the slowest method of getting/setting pixel data. You could easily create your own wrappers that would involve direct pixel access.
> Nothing i've searched on the web, apple's site, or the frameworks gives me any indication of what i'm trying to do. the closest thing i can come up with is coreimage but i'm unsure on how it works and it can't invert the color data.
>
Depending on your speed needs, CI may not be the best. I had thought of using CI to do my grayscale effect. However, since both my input and output needed to be an NSBitmapImageRep, I'd spend too much time copying image data around to convert to/from formats needed by CI. So, at a Tiger Tech talk, an Apple engineer proposed I stick with the direct pixel access approach.
> implementing an apple2 hi-res graphics screen is the main thrust for this program segment. more specifically, the apple pascal's turtlegraphics routines in their entirety (other than textmode and grafmode procedures) for script programmers.
Hmm...how do you plan (if at all) to support anti-aliasing? If you're doing a simple drawing app, why not just draw with NSBezierPath?
--
Rick Sharp
Instant Interactive(tm) -
On 24/gen/06, at 06:15, John Stiles wrote:
> The problem here is that Core Graphics doesn't really work in terms
> of "pixels" per se. It's built around resolution-independent vector
> graphics concepts. For example, you can apply a transformation
> matrix to the view which will skew, rotate or scale it. So
> conceptually, there really aren't any "pixels" for you to get at,
> unfortunately.
>
> I don't think CG offers an "invert" fill mode either,
> unfortunately. I can't see any conceptual reason why not. My only
> hunch is maybe that "invert" doesn't seem very useful in a
> PostScript world, and CoreGraphics is descended from Display
> PostScript.
Actually, using kCGBlendModeDifference with a fully-white source
image should invert the colors of the background image (1.0 - c).
Camillo -
On Jan 23, 2006, at 5:05 PM, Robert Dell wrote:
> Since invertrect is going to be depreciated, what are my choices
> for doing what it does?
That depends on what you're drawing. Are they 1-bit deep pixmaps?
Are they Quickdraw PICTs? TIFF Images?
-jcr -
Camillo Lugaresi wrote:
> On 24/gen/06, at 06:15, John Stiles wrote:Sweet, I looked around but didn't see that one. Does that mean the OP
>
>> The problem here is that Core Graphics doesn't really work in terms
>> of "pixels" per se. It's built around resolution-independent vector
>> graphics concepts. For example, you can apply a transformation matrix
>> to the view which will skew, rotate or scale it. So conceptually,
>> there really aren't any "pixels" for you to get at, unfortunately.
>>
>> I don't think CG offers an "invert" fill mode either, unfortunately.
>> I can't see any conceptual reason why not. My only hunch is maybe
>> that "invert" doesn't seem very useful in a PostScript world, and
>> CoreGraphics is descended from Display PostScript.
>
> Actually, using kCGBlendModeDifference with a fully-white source image
> should invert the colors of the background image (1.0 - c).
>
/can/ draw inverted rects with CG? -
On 24/gen/06, at 16:47, John Stiles wrote:
>
> Camillo Lugaresi wrote:
>> On 24/gen/06, at 06:15, John Stiles wrote:
>>
>>> The problem here is that Core Graphics doesn't really work in
>>> terms of "pixels" per se. It's built around resolution-
>>> independent vector graphics concepts. For example, you can apply
>>> a transformation matrix to the view which will skew, rotate or
>>> scale it. So conceptually, there really aren't any "pixels" for
>>> you to get at, unfortunately.
>>>
>>> I don't think CG offers an "invert" fill mode either,
>>> unfortunately. I can't see any conceptual reason why not. My only
>>> hunch is maybe that "invert" doesn't seem very useful in a
>>> PostScript world, and CoreGraphics is descended from Display
>>> PostScript.
>>
>> Actually, using kCGBlendModeDifference with a fully-white source
>> image should invert the colors of the background image (1.0 - c).
>>
> Sweet, I looked around but didn't see that one. Does that mean the
> OP can draw inverted rects with CG?
Sure, as long as he can require 10.4. Try putting this custom view in
one of your windows:
static inline CGRect CGRectFromNSRect(NSRect nsRect) { return *
(CGRect*)&nsRect; }
@implementation InvertView
- (void)drawRect:(NSRect)rect
{
CGContextRef context = (CGContextRef)[[NSGraphicsContext
currentContext] graphicsPort];
CGContextSaveGState (context);
CGContextSetBlendMode(context, kCGBlendModeDifference);
CGContextSetRGBFillColor (context, 1.0, 1.0, 1.0, 1.0);
CGContextFillRect (context, CGRectFromNSRect(rect));
CGContextRestoreGState (context);
}
@end
(put some other controls under it, since the effect might be hard to
appreciate with just the window background)
Camillo -
Ricky Sharp wrote:
> On Monday, January 23, 2006, at 10:42PM, Robert Dell <dellr...> wrote:
>> yes, i actually need to invert the color pixels within the rectangle.
>> if i had access to the actual pixels, i could invert them myself (although that wouldn't be the fastest way) one pixel at a time.
> Just what kind of speed do you need? I use direct pixel access of an NSBitmapImageRep and perform convert-to-grayscale (NTSC weighted algorithm) of 1024x768 images. On a dual 2GHz G5, it's only a few microseconds.
i'd like to see the code you used for that.
>> i also need to read and set individual pixels the same way getcpixel and setcpixel did.
> Those two routines were the slowest method of getting/setting pixel data. You could easily create your own wrappers that would involve direct pixel access.
>> Nothing i've searched on the web, apple's site, or the frameworks gives me any indication of what i'm trying to do. the closest thing i can come up with is coreimage but i'm unsure on how it works and it can't invert the color data.
> Depending on your speed needs, CI may not be the best. I had thought of using CI to do my grayscale effect. However, since both my input and output needed to be an NSBitmapImageRep, I'd spend too much time copying image data around to convert to/from formats needed by CI. So, at a Tiger Tech talk, an Apple engineer proposed I stick with the direct pixel access approach.
>> implementing an apple2 hi-res graphics screen is the main thrust for this program segment. more specifically, the apple pascal's turtlegraphics routines in their entirety (other than textmode and grafmode procedures) for script programmers.
> Hmm...how do you plan (if at all) to support anti-aliasing? If you're doing a simple drawing app, why not just draw with NSBezierPath?
everything i read about nsbezierpath says it's for drawing closed items such as rectnngles, squares, circles. etc... something that closes up. i'm drawing open things.
also for somebody to create graphics in a text only script and then have my drawblock routine convert the text to color pixels (if it's a space it's black, if it's a number then it's a user color, if it's anything else it's white... and all that gets mixed with the background with 16 modes)
mode: meaning:
0 ignore bit pattern (color = black)
1 logical NOR with screen
2 logical AND with screen complement
3 screen complement
4 logical AND complement with screen
5 complement
6 logical XOR with screen
7 logical NAND with screen
8 logical AND with screen
9 equivilance
10 direct copy
11 logical OR with screen complement
12 screen replacement
13 logical OR complement with screen
14 logical OR with screen
15 ignore bit pattern (color = white) -
On Jan 24, 2006, at 6:38 PM, Robert Dell wrote:
> everything i read about nsbezierpath says it's for drawing closed
> items such as rectnngles, squares, circles. etc... something that
> closes up.
The first paragraph of the "Class Description" for NSBezierPath says
otherwise:
> An NSBezierPath object allows you to create paths using PostScript-
> style commands. Paths consist of straight and curved line segments
> joined together. Paths can form recognizable shapes such as
> rectangles, ovals, arcs, and glyphs; they can also form complex
> polygons using either straight or curved line segments. A single
> path can be closed by connecting its two endpoints, or it can be
> left open.
--Andy
