Re: NSView and rectangle management
Re: NSView and rectangle management
- Subject: Re: NSView and rectangle management
- From: "John C. Randolph" <email@hidden>
- Date: Tue, 25 Jun 2002 11:20:48 -0700
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.
-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
_______________________________________________
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.