On Nov 23, 2009, at 11:28 PM, Christopher Hunt wrote:
> Interestingly I see that the odd call takes over 34ms - this will presumably cause my animation to skip a frame:
> 34580.81 µs glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
> 0.59 µs glFlushRenderAPPLE();
I have finally been able to get the OpenGL profiler to work with my plugin - normally, Safari would just freeze when i tried to attach the the WebKitPluginHost, but now I tried running Safari in 32-bit mode, which makes the plugin run in the same process, and there it worked.
What I'm seeing, when running content which suffers from the problem is this:
CGLFlushDrawable, Avg Time 104294.94µs (104 ms!), GL Time: 99.44% (!!!)
We never call CGLFlushDrawable from our own code, it's only being called here, from a seperate thread:
#0 0x96985c9d in CGLFlushDrawable
#1 0x915c1e79 in view_draw
#2 0x915c0fd7 in view_display_link
#3 0x915c0f2b in link_callback
#4 0x9027f440 in CVDisplayLink::performIO
#5 0x9027e0a8 in CVDisplayLink::runIOThread
#6 0x9027dcd0 in startIOThread
#7 0x94df1fbd in _pthread_start
#8 0x94df1e42 in thread_start
I also noticed that this problem seems to be related to our usage of real-time shadows (for which we use FBOs to render the shadow maps). If I disable those, the problem goes away (at least for the content I tested - there may be other ways to trigger it).
(Sorry to be spamming quartz-dev with my daily findings like this, but this is a serious regression from the old plugin model, and we are really stepping in the dark on how to solve it).
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden