OpenGL and Tiger
-
Hi,
I compiled my OpenGL app with XCode 2.0.
On Panther is everything ok. On Tiger I get this problem.
When another window of another application (e.g. a Finder window, an XCode
window...) is over my OpenGL window (even partially), that application runs
very very slow. If I drag that window out of the OpenGL window, that program
turns back to work well.
It's a very annoying problem. I cannot use my application this way.
Do you know how to fix this problem?
Best Regards
--
Lorenzo
email: <archidea...> -
On May 14, 2005, at 10:54 AM, Lorenzo wrote:
> Hi,
> I compiled my OpenGL app with XCode 2.0.
> On Panther is everything ok. On Tiger I get this problem.
> When another window of another application (e.g. a Finder window,
> an XCode
> window...) is over my OpenGL window (even partially), that
> application runs
> very very slow. If I drag that window out of the OpenGL window,
> that program
> turns back to work well.
>
> It's a very annoying problem. I cannot use my application this way.
> Do you know how to fix this problem?
What does this have to do with Cocoa development (the subject of the
Cocoa dev list)? Please avoid cross posting and keep it relevant if
you do.
Anyways try using Shark and/or OpenGL profiler (etc.) to understand
what is going on. Likely folks with need more information then what
you provided above (what does your GL application do, what hardware
are you seeing this on, etc.).
A side note I don't see what you describe above happening on my Dual
2GHz G5 with 6800 GT (and two 23" monitors attached) when using one
of the GLUT examples ("atlantis timing"). I however do see the GLUT
example slowing down its animation to the refresh rate of the monitor
when the shadow of another window is over the examples content. The
example uses glutSwapBuffers at the end of each draw cycle. It stands
to reason when the window is not overlaid by any other window (aka
opengl surfaces) then buffer swapping can happen as fast as the
hardware can do it. If a window overlays things then it is likely
clamped to the swap rate of window manager for its surfaces which
likely is no faster then the display refresh rate (I have only LCDs
at home so I cannot twiddle with refresh rates to confirm).
-Shawn -
On May 14, 2005, at 11:16 AM, Shawn Erickson wrote:
> On May 14, 2005, at 10:54 AM, Lorenzo wrote:
>
>> I compiled my OpenGL app with XCode 2.0.
>> On Panther is everything ok. On Tiger I get this problem.
>> When another window of another application (e.g. a Finder window,
>> an XCode
>> window...) is over my OpenGL window (even partially), that
>> application runs
>> very very slow. If I drag that window out of the OpenGL window,
>> that program
>> turns back to work well.
>
> A side note I don't see what you describe above happening on my
> Dual 2GHz G5 with 6800 GT (and two 23" monitors attached) when
> using one of the GLUT examples ("atlantis timing"). I however do
> see the GLUT example slowing down its animation to the refresh rate
> of the monitor when the shadow of another window is over the
> examples content. The example uses glutSwapBuffers at the end of
> each draw cycle. It stands to reason when the window is not
> overlaid by any other window (aka opengl surfaces) then buffer
> swapping can happen as fast as the hardware can do it. If a window
> overlays things then it is likely clamped to the swap rate of
> window manager for its surfaces which likely is no faster then the
> display refresh rate (I have only LCDs at home so I cannot twiddle
> with refresh rates to confirm).
This is a very real problem, and affects graphics performance for
most app's. In profiling, glFlush() takes approx 5 times longer to
complete on Tiger vs. Panther. Window dragging is slower, and drops
to 1/3 speed or less when a window spans more than one display, and
on my Radon 9000 is slower on the non-main display. It's as if CGS
is attempting to force VBL sync "again", competing with other sync
API's. Several bugs filed. I'd post the #'s but Radar is currently
down.
--
Shaun Wexler
MacFOH
http://www.macfoh.com -
Thank you Shaun,
did you file a bug to <devbugs...> ?
If not, I will do it, if you didn't yet plan to do it by yourself.
My application cannot be sold this way :-(
Best Regards
--
Lorenzo
email: <archidea...>
> From: Shaun Wexler <dev...>
> Date: Sat, 14 May 2005 11:48:51 -0700
> To: Shawn Erickson <shawn...>
> Cc: Lorenzo <archidea...>, Mac List OpenGL <mac-opengl...>,
> Cocoa List <cocoa-dev...>
> Subject: Re: OpenGL and Tiger
>
> On May 14, 2005, at 11:16 AM, Shawn Erickson wrote:
>
>> On May 14, 2005, at 10:54 AM, Lorenzo wrote:
>>
>>> I compiled my OpenGL app with XCode 2.0.
>>> On Panther is everything ok. On Tiger I get this problem.
>>> When another window of another application (e.g. a Finder window,
>>> an XCode
>>> window...) is over my OpenGL window (even partially), that
>>> application runs
>>> very very slow. If I drag that window out of the OpenGL window,
>>> that program
>>> turns back to work well.
>>
>> A side note I don't see what you describe above happening on my
>> Dual 2GHz G5 with 6800 GT (and two 23" monitors attached) when
>> using one of the GLUT examples ("atlantis timing"). I however do
>> see the GLUT example slowing down its animation to the refresh rate
>> of the monitor when the shadow of another window is over the
>> examples content. The example uses glutSwapBuffers at the end of
>> each draw cycle. It stands to reason when the window is not
>> overlaid by any other window (aka opengl surfaces) then buffer
>> swapping can happen as fast as the hardware can do it. If a window
>> overlays things then it is likely clamped to the swap rate of
>> window manager for its surfaces which likely is no faster then the
>> display refresh rate (I have only LCDs at home so I cannot twiddle
>> with refresh rates to confirm).
>
> This is a very real problem, and affects graphics performance for
> most app's. In profiling, glFlush() takes approx 5 times longer to
> complete on Tiger vs. Panther. Window dragging is slower, and drops
> to 1/3 speed or less when a window spans more than one display, and
> on my Radon 9000 is slower on the non-main display. It's as if CGS
> is attempting to force VBL sync "again", competing with other sync
> API's. Several bugs filed. I'd post the #'s but Radar is currently
> down.
> --
> Shaun Wexler
> MacFOH
> http://www.macfoh.com
>
>
-
On May 15, 2005, at 9:58 AM, Lorenzo wrote:
> Thank you Shaun,
> did you file a bug to <devbugs...> ?
> If not, I will do it, if you didn't yet plan to do it by yourself.
Yes, I've filed several bugs on each, and I strive to retest and
update all relevant reports when each new seed is released.
> My application cannot be sold this way :-(
MacFOH still sustains 75 fps (max VBL) on all windows across all
screens, except the occluded windows which drop to 37.25 (50%). This
isn't the app's fault... the latency bug is in CGS (CoreGraphics
Window Server). When I boot back into Panther, everything feels
noticeably faster on the desktop, regarding graphics and event-
processing, menus, controls, etc.
--
Shaun Wexler
MacFOH
http://www.macfoh.com -
On May 15, 2005, at 3:50 PM, Shaun Wexler wrote:
> On May 15, 2005, at 9:58 AM, Lorenzo wrote:
>
>> Thank you Shaun,
>> did you file a bug to <devbugs...> ?
>> If not, I will do it, if you didn't yet plan to do it by yourself.
>
> Yes, I've filed several bugs on each, and I strive to retest and
> update all relevant reports when each new seed is released.
>
>> My application cannot be sold this way :-(
>
> MacFOH still sustains 75 fps (max VBL) on all windows across all
> screens, except the occluded windows which drop to 37.25 (50%). This
> isn't the app's fault... the latency bug is in CGS (CoreGraphics
> Window Server). When I boot back into Panther, everything feels
> noticeably faster on the desktop, regarding graphics and
> event-processing, menus, controls, etc.
A posting to the Carbon list on Friday (5/13) mentioned a change to the
HIToolbox that can cause a slowdown (on purpose) if you try to draw
faster than the video card's frame rate. This may be related to what
you're seeing. The archived message is at:
http://lists.apple.com/archives/carbon-dev/2005/May/msg00632.html
steve -
On May 15, 2005, at 8:39 PM, Steve Christensen wrote:
> A posting to the Carbon list on Friday (5/13) mentioned a change to
> the HIToolbox that can cause a slowdown (on purpose) if you try to
> draw faster than the video card's frame rate. This may be related
> to what you're seeing.
This is the document they refer to (and please note the constant
disclaimers for the performance-zapping "feature"):
http://developer.apple.com/releasenotes/Carbon/HIToolbox.html
If beam synchronization is disabled using Quartz Debug, everything
works properly again. I confirmed this with MacFOH, and all windows
maintain 75 fps regardless if they're occluded and being composited.
According to the above doc, only apps linked against 10.4 will use
the "automatic" beam sync. It is definitely a bug in CGS: all apps
are being force-synchronized (regardless of executable link), and
unfortunately this feature SUCKS to begin with. Anything forcibly
imposed on developers further restricts our ability to provide high-
performance without making constant workarounds for these
"conveniences". If the API were nicely rolled into CG, NSScreen,
etc, then it would be more useful. If this behavior was in fact only
enabled by the link version of the executable, I'm in luck, because I
can build just the executable with Panther, and everything else with
Tiger if necessary, hopefully avoiding this sync issue.
On a good note, using Quartz Debug to turn off beam synchronization
globally actually makes Tiger seem fast, like Panther. I'm never
turning it back on... ;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com -
On May 16, 2005, at 1:04 AM, Shaun Wexler wrote:
> On a good note, using Quartz Debug to turn off beam synchronization
> globally actually makes Tiger seem fast, like Panther. I'm never
> turning it back on... ;)
Yep, you're right. Also interesting is that while automatic beam
synchronization is off, it tears considerably more often than Panther
ever did. Still, I'm leaving it off as well. A PowerMac G4 Dual
800mhz shouldn't have to stutter while moving windows around.
:-/
chaz -
Glad to know there is workaround.
I launch Quartz Debug and mark the radio button
"Disable Beam Synchronization". Now my application works well, the
refreshing problem has gone. Then I quit Quartz Debug and my application's
problem occurs again. I launch again Quartz Debug and strangely the radio
button "Disable Beam Synchronization" is not marked anymore.
How to set it permanently? And, most of all,
do I have to say to all of my clients to do this settings by themselves?
I hope no.
Best Regards
--
Lorenzo
email: <archidea...>
> From: Shaun Wexler <dev...>
> Date: Mon, 16 May 2005 00:04:35 -0700
> To: Steve Christensen <punster...>
> Cc: Shawn Erickson <shawn...>, Lorenzo <archidea...>, Simon
> Clarke <simon...>, Cocoa-Dev <cocoa-dev...>,
> Mac-OpenGL <mac-opengl...>, <quartz-dev...>
> Subject: Re: OpenGL and Tiger
>
> On May 15, 2005, at 8:39 PM, Steve Christensen wrote:
>
>> A posting to the Carbon list on Friday (5/13) mentioned a change to
>> the HIToolbox that can cause a slowdown (on purpose) if you try to
>> draw faster than the video card's frame rate. This may be related
>> to what you're seeing.
>
> This is the document they refer to (and please note the constant
> disclaimers for the performance-zapping "feature"):
>
> http://developer.apple.com/releasenotes/Carbon/HIToolbox.html
>
> If beam synchronization is disabled using Quartz Debug, everything
> works properly again. I confirmed this with MacFOH, and all windows
> maintain 75 fps regardless if they're occluded and being composited.
>
> According to the above doc, only apps linked against 10.4 will use
> the "automatic" beam sync. It is definitely a bug in CGS: all apps
> are being force-synchronized (regardless of executable link), and
> unfortunately this feature SUCKS to begin with. Anything forcibly
> imposed on developers further restricts our ability to provide high-
> performance without making constant workarounds for these
> "conveniences". If the API were nicely rolled into CG, NSScreen,
> etc, then it would be more useful. If this behavior was in fact only
> enabled by the link version of the executable, I'm in luck, because I
> can build just the executable with Panther, and everything else with
> Tiger if necessary, hopefully avoiding this sync issue.
>
> On a good note, using Quartz Debug to turn off beam synchronization
> globally actually makes Tiger seem fast, like Panther. I'm never
> turning it back on... ;)
> --
> Shaun Wexler
> MacFOH
> http://www.macfoh.com
>
>
-
On May 16, 2005, at 2:16 AM, Lorenzo wrote:
> Glad to know there is workaround.
> I launch Quartz Debug and mark the radio button
> "Disable Beam Synchronization". Now my application works well, the
> refreshing problem has gone. Then I quit Quartz Debug and my
> application's
> problem occurs again. I launch again Quartz Debug and strangely the
> radio
> button "Disable Beam Synchronization" is not marked anymore.
>
> How to set it permanently? And, most of all,
> do I have to say to all of my clients to do this settings by
> themselves?
> I hope no.
Quartz Debug resets the mode to "automatic" when it quits. The
Window Server debug state is global for the session, not per-process
or per-window. If your app disables it, it should re-enable it upon
quit; you should present a warning dialog to the user and let them
make the decision. Here is the necessary code:
extern void CGSSetDebugOptions(int);
extern void CGSDeferredUpdates(int);
typedef enum {
disableBeamSync = 0,
automaticBeamSync = 1,
forcedBeamSyncMode = 2
} beamSyncMode;
beamSyncOption mode = disableBeamSync;
CGSSetDebugOptions(mode ? 0 : 0x08000000);
CGSDeferredUpdates(mode);
All disclaimers shall apply. ;)~
--
Shaun Wexler
MacFOH
http://www.macfoh.com
"Problems cannot be solved by the same level of thinking that created
them." - Albert Einstein -
On May 16, 2005, at 2:04 AM, Shaun Wexler wrote:
> On May 15, 2005, at 8:39 PM, Steve Christensen wrote:
>
> According to the above doc, only apps linked against 10.4 will use
> the "automatic" beam sync. It is definitely a bug in CGS: all
> apps are being force-synchronized (regardless of executable link),
> and unfortunately this feature SUCKS to begin with. Anything
> forcibly imposed on developers further restricts our ability to
> provide high-performance without making constant workarounds for
> these "conveniences". If the API were nicely rolled into CG,
> NSScreen, etc, then it would be more useful. If this behavior was
> in fact only enabled by the link version of the executable, I'm in
> luck, because I can build just the executable with Panther, and
> everything else with Tiger if necessary, hopefully avoiding this
> sync issue.
>
> On a good note, using Quartz Debug to turn off beam synchronization
> globally actually makes Tiger seem fast, like Panther. I'm never
> turning it back on... ;)
What benefit are you enjoying by refreshing your window faster than
the screen can keep up with you?
Scott -
On May 16, 2005, at 7:15 AM, Scott Thompson wrote:
> What benefit are you enjoying by refreshing your window faster than
> the screen can keep up with you?
Tiger's auto-beam-sync has ~bugs~. It does not work properly;
hopefully it will be fixed soon. It should have been obvious that
forcing a blocking implementation was the wrong approach...
FWIW, MacFOH uses its own custom beam synchronizer.
--
Shaun Wexler
MacFOH
http://www.macfoh.com -
Please note that CGSSetDebugOptions() and other CGS functions are
private SPI. Parameters to CGSSetDebugOptions() in particular will
change from one release to the next. Do not be surprised if the
behavior of your application varies unpredictably across releases.
(Some debug option bits do things like trigger abort() calls under
interesting conditions, such as error conditions. Your users may not
appreciate such behaviors.)
Think of it as evolution in action...
Mike Paquette
On May 16, 2005, at 6:31 AM, Shaun Wexler wrote:
> Here is the necessary code:
>
> extern void CGSSetDebugOptions(int);
>
-
On May 16, 2005, at 6:31 AM, Shaun Wexler wrote:
> On May 16, 2005, at 2:16 AM, Lorenzo wrote:
>
>
>> Glad to know there is workaround.
>> I launch Quartz Debug and mark the radio button
>> "Disable Beam Synchronization". Now my application works well, the
>> refreshing problem has gone. Then I quit Quartz Debug and my
>> application's
>> problem occurs again. I launch again Quartz Debug and strangely
>> the radio
>> button "Disable Beam Synchronization" is not marked anymore.
>>
>> How to set it permanently? And, most of all,
>> do I have to say to all of my clients to do this settings by
>> themselves?
>> I hope no.
>>
>
> Quartz Debug resets the mode to "automatic" when it quits. The
> Window Server debug state is global for the session, not per-
> process or per-window. If your app disables it, it should re-
> enable it upon quit; you should present a warning dialog to the
> user and let them make the decision. Here is the necessary code:
>
> extern void CGSSetDebugOptions(int);
> extern void CGSDeferredUpdates(int);
>
> typedef enum {
> disableBeamSync = 0,
> automaticBeamSync = 1,
> forcedBeamSyncMode = 2
> } beamSyncMode;
>
> beamSyncOption mode = disableBeamSync;
>
> CGSSetDebugOptions(mode ? 0 : 0x08000000);
> CGSDeferredUpdates(mode);
>
> All disclaimers shall apply. ;)~
I'll add a disclaimer... note that Quartz 2D Extreme is something
Apple has available for developers to test with and I bet this beam
synchronization mode may allow some level of optimization to take
place in relation to Q2DX. So be careful depending on this being set
certain ways until we hear more from Apple in this space (likely
better discussed on the Quartz list, so let stop with the cross
posting and take it just one list).
I bet at WWDC 2005 Apple will outline things at a more detailed level.
-Shawn -
I'm working on a video mixer application which uses the Core Video
display link thread to render Quicktime movie frames as OpenGL
textures. This problem doesn't seem to be effecting my application.
Are you saying that auto-beam-sync doesn't work as advertised, or you
think that blocking in flush() when drawing faster than the screen
refresh rate is a "Bad Idea"?
- Scott
On May 16, 2005, at 10:20 AM, Shaun Wexler wrote:
> On May 16, 2005, at 7:15 AM, Scott Thompson wrote:
>
>
>> What benefit are you enjoying by refreshing your window faster
>> than the screen can keep up with you?
>>
>
> Tiger's auto-beam-sync has ~bugs~. It does not work properly;
> hopefully it will be fixed soon. It should have been obvious that
> forcing a blocking implementation was the wrong approach...
>
> FWIW, MacFOH uses its own custom beam synchronizer.
> --
> Shaun Wexler
> MacFOH
> http://www.macfoh.com
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/pixel%
> 40pixelfreak.net
>
> This email sent to <pixel...>
>
>
>
- - -
:: <pixel...>
:: http://www.pixelfreak.net
- - - -
Thank you Shaun and Mike.
The Shaun's solution almost works but now a new problem occurs.
When another window occludes my OpenGL window, even partially, well, now my
animation runs at a higher speed. Too much. It is not synchronized anymore
with the display refresh rate. My app it's supposed to run at the display
refresh rate, so I can get the max smooth quality. So the Shaun's solution
as it is actually, is not useful for me.
Yes, Mike. You are right, it's better to avoid bad surprises to the users,
... but how to fix this problem?
I cannot put another application's window over my application window. If I
do, this top application runs very very slowly. For example, I cannot drag a
file onto my application because once I open a Finder window over my OpenGL
application window, the Finder gets stuck. Opening a subfolder requires 10
seconds... tipyng a text string other 10 seconds. Selecting a string on my
XCode window requires 5 seconds about...
I cannot sell my application this way. And I invested many months in this
project. The problem never occurred with Panther, so please let me know how
to workaround the problem.
Best Regards
--
Lorenzo
email: <archidea...>
> From: Mike Paquette <mpaque...>
> Date: Mon, 16 May 2005 07:38:45 -0700
> To: Shaun Wexler <dev...>
> Cc: Lorenzo <archidea...>, Cocoa-Dev <cocoa-dev...>, Shawn
> Erickson <shawn...>, Simon Clarke <simon...>,
> <quartz-dev...>, Mac-OpenGL <mac-opengl...>
> Subject: Re: OpenGL and Tiger
>
> Please note that CGSSetDebugOptions() and other CGS functions are
> private SPI. Parameters to CGSSetDebugOptions() in particular will
> change from one release to the next. Do not be surprised if the
> behavior of your application varies unpredictably across releases.
> (Some debug option bits do things like trigger abort() calls under
> interesting conditions, such as error conditions. Your users may not
> appreciate such behaviors.)
>
> Think of it as evolution in action...
>
> Mike Paquette
>
> On May 16, 2005, at 6:31 AM, Shaun Wexler wrote:
>
>> Here is the necessary code:
>>
>> extern void CGSSetDebugOptions(int);
>>
>
-
On May 16, 2005, at 8:40 AM, Lorenzo wrote:
> Thank you Shaun and Mike.
>
> The Shaun's solution almost works but now a new problem occurs.
> When another window occludes my OpenGL window, even partially,
> well, now my
> animation runs at a higher speed. Too much. It is not synchronized
> anymore
> with the display refresh rate. My app it's supposed to run at the
> display
> refresh rate, so I can get the max smooth quality. So the Shaun's
> solution
> as it is actually, is not useful for me.
>
> Yes, Mike. You are right, it's better to avoid bad surprises to the
> users,
> ... but how to fix this problem?
> I cannot put another application's window over my application
> window. If I
> do, this top application runs very very slowly. For example, I
> cannot drag a
> file onto my application because once I open a Finder window over
> my OpenGL
> application window, the Finder gets stuck. Opening a subfolder
> requires 10
> seconds... tipyng a text string other 10 seconds. Selecting a
> string on my
> XCode window requires 5 seconds about...
> I cannot sell my application this way. And I invested many months
> in this
> project. The problem never occurred with Panther, so please let me
> know how
> to workaround the problem.
I would file a defect with Apple and consider contacting DTS [1] if
you want Apple to help you directly on this issue (likely get you to
any possible work around more quickly).
As I noted earlier I don't see this issue (the one you outline above)
so please outline what hardware is involved in your testing. I have a
feeling it is ATI or possibly single CPU related. Please feel free to
fire me a copy of something that you want tested on my setup here.
(again may I suggest we take this to just one list, as it is now we
have 3 separate threads taking place on thread separate mailings list
each with a different mix of messages... sounds like the quartz list
or opengl list would be best)
-Shawn
[1] <http://developer.apple.com/technicalsupport/index.html> -
On May 16, 2005, at 8:12 AM, Scott Ahten wrote:
> I'm working on a video mixer application which uses the Core Video
> display link thread to render Quicktime movie frames as OpenGL
> textures. This problem doesn't seem to be effecting my application.
I can set a prefs value and MacFOH will utilize CVDisplayLink instead
of SKWDisplay VBL sync. The results of profiling using the same
setup and realtime analyzer document are:
CVDisplayLink
Tiger 10.4.1
CGS Beam Sync enabled
4.93% OpenGL
glFlush 410 µS
SKWDisplay
Tiger 10.4.1
CGS Beam Sync enabled
3.88% OpenGL
glFlush 256 µS
CVDisplayLink
Tiger 10.4.1
CGS Beam Sync disabled
3.00% OpenGL
glFlush 128 µS
SKWDisplay
Tiger 10.4.1
CGS Beam Sync disabled
2.87% OpenGL
glFlush 107 µS
SKWDisplay
Panther 10.3.9
1.32% OpenGL
glFlush 62 µS
> Are you saying that auto-beam-sync doesn't work as advertised
So far, it does not improve performance, in fact it is quite the
opposite. Its implementation needs to be rethought.
> or you think that blocking in flush() when drawing faster than the
> screen refresh rate is a "Bad Idea"?
I think introducing blocking to anything (especially something that
didn't previously block) is generally a bad idea, unless it's a
specific API designed to block. Completion callbacks would be
better, and allow developers to elect their use.
I designed an API for rendering management that is superior IMO, and
it would be great to incorporate it into OpenGL/CGS/CV so everything
would enjoy the same high performance and low latency as MacFOH
(under Panther). Until these glaring Tiger/CGS bugs are resolved,
I'm staying with Panther, and will continue to recommend that my
users resist upgrading. Dual-monitor window dragging on Tiger is
currently so pathetic that I can't even read the window contents
because it jitters so badly when windows cross the screen boundary.
Previous seeds in the range 393-414 provided substantially better
performance, then it was broken again.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
"Intellectuals solve problems, geniuses prevent them." - Albert Einstein -
On May 14, 2005, at 11:48 AM, Shaun Wexler wrote:
> This is a very real problem, and affects graphics performance for
> most app's. In profiling, glFlush() takes approx 5 times longer to
> complete on Tiger vs. Panther. Window dragging is slower, and
> drops to 1/3 speed or less when a window spans more than one
> display, and on my Radon 9000 is slower on the non-main display.
> It's as if CGS is attempting to force VBL sync "again", competing
> with other sync API's. Several bugs filed. I'd post the #'s but
> Radar is currently down.
I found a partial solution to the slowdown of occluded GL surface
drawing. If you perform glFlush in the CVDisplayLink callback,
without prior lFlushRenderAPPLE(), drawing latency will be 1 extra
frame but at full VBL without the occlusion slowdown, though it tears
(ie auto beam-sync doesn't work well). Best solution under Tiger so
far, but still poor performance.
--
Shaun Wexler
MacFOH
http://www.macfoh.com


