| Just for completeness, I attempted the NSOpenGLContext route. If I don't specify NSOpenGLPFADoubleBuffer in the attributes (which I assume not including it in the attribs makes it a single buffered context), the QCRenderer won't even appear in regular Safari (though it does w/ doublebuffer enabled). Regardless, neither value causes it to work in Dashboard, but I've not used NSOpenGLContext at all before, so this one definitely could be operator error ... Essentially I'm just using a highly hacked version of the Player example with fullscreen disabled and attached to a view. I logged a radar bug on the original problem, so maybe we'll see a 10.4.x fix for it someday.
Thanks for you help -- ms On Apr 30, 2005, at 6:05 PM, Pierre-Olivier Latour wrote:
I remember now what the problem is (as I tried that myself some time ago): on top of the don't-start-rendering-before-the-widget-window-is-on-screen issue, there is some incompatibility between NSOpenGLContext, which the QCView uses a certain way, and Dashboard. That prevents using QCView inside Dashboard. You can fill a radar on the issue if you want.
Given what you have access to, the workaround is to create your own hw-accelerated NSOpenGLContext, which must be single-buffered, and set its view to the WebKit plugin view. Then create a QCRenderer from the .qtz file and with this NSOpenGLContext. Finallly, use the QCRenderer instead of the QCView as the _javascript_ object.
/Developer/Examples/Quartz Composer/Player is a sample code on how to use NSOpenGLContext and QCRenderer
________________________________________________________ Quartz Composer Architect Graphic & Imaging Team
|
