Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Programming / Mac Programming / October 2006



Tip: Looking for answers? Try searching our database.

screen refresh (vbl) synchronization behavior on Intel Macs

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
aaronsg@sas.upenn.edu - 23 Oct 2006 19:23 GMT
Hello,

I co-maintain a library which uses OpenGL to synchronize screen updates
to the Vertical Blanking Loop (VBL).

I currently have two problems with OpenGL on Mac OS X for Intel.

1) On both Mac OS X (for PPC) and Linux, we observe the following
behavior:
A call to GL_SwapBuffers blocks if and only if a call to GL_SwapBuffers
has occurred within 1/(frame-rate) seconds ago.  On a 60 Hz screen,
this means that given a call to GL_SwapBuffers at time t followed by
one at time t+15 milliseconds, the second will definitely block for
some (nonzero) time interval.  Given a delay of t+19 milliseconds,
however, the second call will NOT block.

On Mac OS X for Intel, however, the second call does not block even
when it occurs within 1/(frame-rate) seconds ago.  Instead, I need to
accumulate THREE prior calls to GL_SwapBuffers within a screen cycle in
order for one to block.

Is difference this a bug or feature?  Is it possible to set how many
calls are accumulated before one blocks?

2)  On the MacMini and MacBook (but not the MacBook Pro), a call to
glCopyPixels takes 34 milliseconds, on average.  Considering on the
PowerPC, MacBook Pro and Linux this call generally takes well under 1
millisecond, this is an unacceptable degradation in performance.  Is
this a bug?  Can anything be done about this?

Thanks,
Aaron
David Phillip Oster - 26 Oct 2006 03:22 GMT
> Hello,
>
[quoted text clipped - 19 lines]
> Is difference this a bug or feature?  Is it possible to set how many
> calls are accumulated before one blocks?

It is a feature. The OpenGL implementation is allowed to decide how many
buffers to allocate. when you call GL_SwapBuffers you get the next
buffer. When the implementation runs out of buffers you are blocked
until a buffer becomes available. (In my experience, your thread
busywaits until a buffer is available, but that was back in Panther.) I
think there might be an info call to tell you how many back buffers
there are, but I just ran a few test frames, and let the calibration
photocell tell me directly what the frame latency was. The value can
differ depending on the video card, and the card's current set up
(x,y,depth, zbuffer, stencil buffers, textures)

> 2)  On the MacMini and MacBook (but not the MacBook Pro), a call to
> glCopyPixels takes 34 milliseconds, on average.  Considering on the
> PowerPC, MacBook Pro and Linux this call generally takes well under 1
> millisecond, this is an unacceptable degradation in performance.  Is
> this a bug?  Can anything be done about this?

This article talks about MacMini OpenGL performance.

http://everythingapple.blogspot.com/2006_02_26_everythingapple_archive.ht
ml
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.