On May 30, 2007, at 00:20, Christopher Hunt wrote:
On 30/05/2007, at 10:42 AM, John Rosasco wrote:
So how about my strategy of disabling/enabling multi threading
depending on what I'm doing i.e. when I start to drag (mouse
down) and stop dragging (mouse up) - is that a decent strategy?
It appears to work well but I'm wondering if I'm better off
flushing strategically as you suggest i.e. within my drawRect and
just prior to the flushBuffer call of my context.
The flushing is a better policy to go by. It effectively allows
you dynamic control of the multithreaded engine without all of the
initialization/tear-down costs.
Thanks for this. Just so that I'm absolutely clear then: I should
call glFlush prior to my context's flushBuffer method *only* when
in multithreaded mode. I'm only asking 'cause calling glFlush isn't
normally necessary when calling flushBuffer.
Calling glFlush before -flushBuffer is unnecessary in all cases. From
the documentation:
"An implicit glFlush is done by flushBuffer before it returns."
You can call glFlush at any time to essentially force force a
synchronization point in the pipeline and drain the MTGL engine's
command/operation queue. So what you want to do is add extra glFlush
calls when user input is occurring with MTGL turned on to effectively
limit the depth of that queue and improve the response time (the
"snappiness") of your application.
Jean-François Roy
--
Co-Founder of MacStorm
/dev/klog. You better pipe that through your mind.
Attachment:
PGP.sig Description: This is a digitally signed message part
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
