Re: Cocoa control in carbon window
Re: Cocoa control in carbon window
- Subject: Re: Cocoa control in carbon window
- From: John Stiles <email@hidden>
- Date: Tue, 10 Jan 2006 15:09:54 -0800
If you're doing any sort of performance tuning, you are a blind man
in a dark room without Shark. It'll be your new best friend :)
On Jan 10, 2006, at 1:52 PM, Philip Dow wrote:
Like I said, I can't be sure, as I don't know exactly how cocoa
handles its method calls and what that requires from the system.
But things do *seem* to be better once I dropped a bulk of the
cocoa code and switched to using carbon for previewing, so I figure
it must have something to do with cocoa... That makes sense to me! =)
You know though, I've never used the profiler or shark. Now would
be a good time to learn how. Will look into it!
-Phil
On Jan 10, 2006, at 10:43 PM, John Stiles wrote:
Since you are using an entirely different approach to process the
video, what makes you think Cocoa has anything to do with it? :)
Seriously, this is about as unscientific as it gets. I'm sure your
new technique is faster, but I can almost guarantee it's not for
the reasons that you think. Now, OpenGL Profiler and Shark would
both be great tools to determine what the actual difference is
coming from. But if you're satisfied with your new code, I guess
you don't have to worry about it.
On Jan 10, 2006, at 12:42 PM, Philip Dow wrote:
The answer is definitely yes. I have faster video previewing in
front of me to prove it.
I believe I'm referring to objective-c messaging, although I
can't be sure as I don't know exactly how this stuff works. That
whole business about cocoa "wrapping" a lot of carbon
functionality as well. I don't know what is happening for
"wrapping" to take place, but I figure, if I can shed that layer,
surely things will be faster.
What I'm trying to do is catpure video and preview it at the same
time. When using an NSOpenGLView to preview the stream, I run
into terrible problems as soon as I start recording, encoding,
and saving the video to disk. Well, it's not terrible, but the
previewing definitely takes a hit. Now, what I'm doing, is using
carbon calls to get an image frame from the video stream,
CGImageRef (Core Graphics image?), and only once that image is
already constructed, rendering it into a view by way of its
graphics context. This completely avoids any NSView messaging
( right words here? ). I don't even have to call setNeedsDisplay!
I thought I would need an HIView to accomplish this, but turns
out not. No need to mix carbon and cocoa objects in a window at all!
-Phil
On Jan 10, 2006, at 8:49 PM, j o a r wrote:
On 10 jan 2006, at 19.46, Philip Dow wrote:
I wanted to do video-stream rendering in the HIView under the
impression that it would be faster without the cocoa overhead.
Am I correct to think that?
What type of "Cocoa overhead" are you referring to here? I'm
almost sure that the answer will be "NO" though.
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden