Re: NSView and rectangle management
Re: NSView and rectangle management
- Subject: Re: NSView and rectangle management
- From: Paul Fox <email@hidden>
- Date: Tue, 25 Jun 2002 21:37:03 +0100
>
It sounds to me like you're trying too hard, and applying
>
premature optimization.
>
>
FWIW, clipping in CoreGraphics is just like Postscript. There's
>
a clip path, and you can always add any other path to the clip
>
path. In the example you describe, you could just add the paths
>
for the frames of the two subviews to the clip path you get when
>
-drawRect: is sent to your view.
>
>
In any case, there's no need for you to implement your own
>
region calculations.
Thanks John. It is slightly premature optimisation but to be honest
it is mandatory. Press down-arrow on my table control takes so long
that when i hit it again, it hasnt finished processing the last one
so it thunders on ahead of me and feels like molasses in liquid
nitrogen. My edit window behaves much better.
Ive been playing with the clip paths but I am confused.
Again - not only the Apple docs are at fault but Ive resorted to using
my PostScript Cookbooks.
I know how to create a clipping region, so that drawing wont occur
outside a rectangle. But how do I create a clipping rectangle, equal
to the [frame] of my view and then subtract the child views. E.g.
I am playing with code like this:
{ NSBezierPath *path = [NSBezierPath bezierPath];
for (winp = winp->win_children; winp; winp = winp->win_next) {
NSBezierPath *path1, *path2;
if ((winp->win_flags & WINF_MANAGED) == 0)
continue;
path1 = [NSBezierPath bezierPathWithRect: NSMakeRect(
winp->win_x,
winp->win_y,
winp->win_width,
winp->win_height)];
[path1 closePath];
[path1 fill];
path2 = [path1 bezierPathByReversingPath];
[path2 addClip];
}
}
Note the call to bezierPathByReversingPath which suffers from
spectacular lack of documentation. Should I just be addClipping only?
thanks
>
-jcr
>
>
On Tuesday, June 25, 2002, at 05:35 AM, Paul Fox wrote:
>
>
> I have a question regarding NSView and children subviews. When
>
> I draw into an NSView (either via drawRect: or lockFocus) the children
>
> get stomped on.
>
>
>
> The docs say that to avoid this problem, Cocoa sends redrawRects:
>
> to the children to avoid the stamping.
>
>
>
> Isnt this terrible inefficient? I cannot think of a worse hack
>
> in a windowing
>
> system. Consider the cost of those redraws.
>
>
>
> So I have been investigating the clipping functions so I can avoid
>
> overwriting and hence having to redraw. But the clipping functions
>
> seem so incomplete it is not true. Windows and X11 provide a suite
>
> of clipping functions so you can add rectangles and subtract rectangles
>
> from a clipped region. These windowing systems have these operations at
>
> their core and are responsible for the natural way these
>
> windowing systems
>
> work, e.g. minimize one window causes a new exposure-region to
>
> be calculated
>
> for underlying windows.
>
>
>
> But the clipping ops in Cocoa and the CG lib are so very primitive.
>
>
>
> Consider this: I have an NSView, with two children. These children
>
> implement my scrollbar (placed at the left and bottom of the
>
> window). Now if I draw into this view, I currently have to send
>
> a setNeedsDisplay: to the two children views, causing them to
>
> redraw themselves
>
> in their entirety. Visually this is ok, but CPU wise, it makes the
>
> machine run like a dog with lead boots.
>
>
>
> In this simple case, I could compute a clipping region by taking
>
> [view frame] and subtracting out the frame: for the two scrollbars.
>
> But what if the scrollbars or subviews were plonked in the middle
>
> of my view - then the region calculation is nontrivial and I end
>
> up implementing complete region and display algorithms in my code.
>
>
>
> In case anyone is interested, my app (a port from Unix and
>
> Windows) utilises
>
> a graphics drawing layer, modelled on X windows, so I have all the
>
> functions like XDrawString and XDrawLine. I am trying to avoid
>
> putting a complete X server into my code to maintain the machine
>
> independence.
>
>
>
> I am trying hard not to smash my machine to bits and give up on Cocoa
>
> as it is so badly and fundamentally flawed. Can anyone suggest what
>
> to do or which docs to read? I have exhausted the Apple docs and the
>
> web (and the mailing list).
>
>
>
> Part II:
>
>
>
> Another question related to lockFocus and displayIfNeeded and friends.
>
> What does displayIfNeeded actually do?
>
>
>
> I can understand lockFocus - set the preferred window to which
>
> subsequent
>
> drawing occurs (specifically the offscreen bitmap).
>
>
>
> "displayIfNeeded" et al - Does it just do a BitBlt from the
>
> offscreen image
>
> to the screen or does it call the redrawRect function? The docs imply
>
> that drawRect gets called.
>
>
>
> In which case I find it dubious as to why they bother doing things
>
> this way. If all that displayIfNeeded and setNeedsDisplay simple
>
> cause the drawRect: to be called, then why dont I just call
>
> them myself?
>
>
>
> I am having a hard time on this - an app that works, but performs
>
> abysmally. My Pentium 75MHz performs better than the 500MHz PPC cpu
>
> (Pentium running Linux or Windows).
>
>
>
> thanks
>
> _______________________________________________
>
> 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.
>
>
>
>
>
John C. Randolph <email@hidden> (408) 974-8819
>
Sr. Cocoa Software Engineer,
>
Apple Worldwide Developer Relations
>
http://developer.apple.com/cocoa/index.html
>
>
>
+-------------------------------------------------------------------------+
| CRiSP - Flexible editor | CRiSP, syn. for BRIEF |#
| | Internet: email@hidden |#
| If you get no reply for | WWW: (mine)
http://www.crisp.demon.co.uk |#
| support, please check your | WWW:
http://www.crisp.com |#
| Reply-To: email address. | WWW:
http://www.pacemaker.co.uk |#
+-------------------------------------------------------------------------+#
###########################################################################
_______________________________________________
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.