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
previous month may 2005 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today