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).
jonas _______________________________________________
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
