Re: Cocoa control in carbon window
Re: Cocoa control in carbon window
- Subject: Re: Cocoa control in carbon window
- From: Philip Dow <email@hidden>
- Date: Tue, 10 Jan 2006 22:52:52 +0100
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:
This email sent to email@hidden