Smalltalk
› Squeak
› Croquet
›
Croquet - Dev
Rendering Performance
Locked
12
12
 
|
Hey everyone - this is my first time posting to the list.
I've been a Mac shareware game developer for a number of years at http://www.batteryacid.org and now I'm jumping straight into croquet. One of the first things to strike me that I haven't been able to improve is the low framerate. In the simplest of demos I'm experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, almost zero vertices or fragments on the screen). I've spent some time using the popular debugging tools and experimenting by rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: and reducing the large number of GL state changes submitted to the driver. Sure it's easy to find obvious places of graphical improvement, but getting little improvement and not finding a clear graphical bottleneck leads me to think there is other limiting in place (or timers that specify how often to render). Is this correct? Thanks for your time, Derek Arndt PS. Does croquet have VBL syncing? |
|
|
On Jun 8, 2007, at 22:11 , Derek Arndt wrote: > Hey everyone - this is my first time posting to the list. > I've been a Mac shareware game developer for a number of years at > http://www.batteryacid.org and now I'm jumping straight into croquet. > > One of the first things to strike me that I haven't been able to > improve is the low framerate. In the simplest of demos I'm > experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, > almost zero vertices or fragments on the screen). I've spent some > time using the popular debugging tools and experimenting by > rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: > and reducing the large number of GL state changes submitted to the > driver. > > Sure it's easy to find obvious places of graphical improvement, but > getting little improvement and not finding a clear graphical > bottleneck leads me to think there is other limiting in place (or > timers that specify how often to render). Is this correct? Did you enable the higherPerformance preference? - Bert - |
|
|
In reply to this post by Derek Arndt
There is a performance flag under the preferences. When this is set
(which is the default) you are rate limited to less than 50 Hz. David Derek Arndt wrote: > Hey everyone - this is my first time posting to the list. > I've been a Mac shareware game developer for a number of years at > http://www.batteryacid.org and now I'm jumping straight into croquet. > > One of the first things to strike me that I haven't been able to > improve is the low framerate. In the simplest of demos I'm > experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, > almost zero vertices or fragments on the screen). I've spent some > time using the popular debugging tools and experimenting by rendering > nothing in TSpace -> RenderSpace:port:depth:ghostFrame: and reducing > the large number of GL state changes submitted to the driver. > > Sure it's easy to find obvious places of graphical improvement, but > getting little improvement and not finding a clear graphical > bottleneck leads me to think there is other limiting in place (or > timers that specify how often to render). Is this correct? > > Thanks for your time, > Derek Arndt > > PS. Does croquet have VBL syncing? |
|
|
Errr.. unset is the default - need to set for higher performance.
David A Smith wrote: > There is a performance flag under the preferences. When this is set > (which is the default) you are rate limited to less than 50 Hz. > > David > > > Derek Arndt wrote: >> Hey everyone - this is my first time posting to the list. >> I've been a Mac shareware game developer for a number of years at >> http://www.batteryacid.org and now I'm jumping straight into croquet. >> >> One of the first things to strike me that I haven't been able to >> improve is the low framerate. In the simplest of demos I'm >> experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, >> almost zero vertices or fragments on the screen). I've spent some >> time using the popular debugging tools and experimenting by rendering >> nothing in TSpace -> RenderSpace:port:depth:ghostFrame: and reducing >> the large number of GL state changes submitted to the driver. >> >> Sure it's easy to find obvious places of graphical improvement, but >> getting little improvement and not finding a clear graphical >> bottleneck leads me to think there is other limiting in place (or >> timers that specify how often to render). Is this correct? >> >> Thanks for your time, >> Derek Arndt >> >> PS. Does croquet have VBL syncing? > |
|
|
In reply to this post by Derek Arndt
Croquet is not designed to be measured by rendering rate.
The point is to synchronize simulations with other nodes, not to flicker the screen or consume CPU and battery power. Thus the rendering is driven by the timing of a scheduler, and leaving idle time is considered a good thing, so the battery lasts longer. Derek Arndt wrote: > Hey everyone - this is my first time posting to the list. > I've been a Mac shareware game developer for a number of years at > http://www.batteryacid.org and now I'm jumping straight into croquet. > > One of the first things to strike me that I haven't been able to > improve is the low framerate. In the simplest of demos I'm > experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, > almost zero vertices or fragments on the screen). I've spent some > time using the popular debugging tools and experimenting by rendering > nothing in TSpace -> RenderSpace:port:depth:ghostFrame: and reducing > the large number of GL state changes submitted to the driver. > > Sure it's easy to find obvious places of graphical improvement, but > getting little improvement and not finding a clear graphical > bottleneck leads me to think there is other limiting in place (or > timers that specify how often to render). Is this correct? > > Thanks for your time, > Derek Arndt > > PS. Does croquet have VBL syncing? > |
|
|
In reply to this post by Derek Arndt
Derek I've never looked at the Open/GL croquet drawing with
relationship to the squeak displayscreen drawing. If you are using the carbon macintosh vm, there are some info.plist parms see http:// www.smalltalkconsulting.com/html/squeakinfoplist.html say SqueakUIFlushPrimaryDeferNMilliseconds which affect drawing performance for the non open/gl stuff. Use of Apple's Shark should tell you where the time is going, and how much clock time is used sitting in the VM is sleeping primitive. On Jun 8, 2007, at 1:11 PM, Derek Arndt wrote: > Hey everyone - this is my first time posting to the list. > I've been a Mac shareware game developer for a number of years at > http://www.batteryacid.org and now I'm jumping straight into croquet. > > One of the first things to strike me that I haven't been able to > improve is the low framerate. In the simplest of demos I'm > experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, > almost zero vertices or fragments on the screen). I've spent some > time using the popular debugging tools and experimenting by > rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: > and reducing the large number of GL state changes submitted to the > driver. > > Sure it's easy to find obvious places of graphical improvement, but > getting little improvement and not finding a clear graphical > bottleneck leads me to think there is other limiting in place (or > timers that specify how often to render). Is this correct? > > Thanks for your time, > Derek Arndt > > PS. Does croquet have VBL syncing? -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
Performance varies wildly! I tried the big demo (the one with all the
friendly face portals) on a Dell D410 (Linux) and got between 30 and 50 fps (it keeps changing), while on a 2GHz G5 iMac (OS X 10.4.9) I only get between 5 and 10 fps. I'll try those special parameters and Shark.... |
|
|
In reply to this post by johnmci
Thanks John,
I'm coming back to this specific issue as I would like to have a better understanding of where the framerate is going. With many optimized objects in the scene I am unable to obtain an acceptable framerate and I can't help but feel I'm being limited by the rate of which key methods are being fired in squeak. I've adjusted the configuration in the plist without any noticeable results. Below is a link to the shark profile - I'm not used to reading much outside of the application's symbols (and because this code isn't a C the results aren't very useful for the app itself). I'm interested to see what you can gleam from the profile if anything: Interestingly enabling higherPerformance doesn't change the low framerate when rendering many objects on screen (which I would take to mean the bottleneck is in rendering the objects - but the framerates are much less then I would expect) Thanks for your time John, Derek On Jul 20, 2007, at 10:46 AM, Peter Moore wrote:
|
|
|
You are not bottlenecked by Squeak, but instead are idle. And the
reason is quite simple, I suspect. Croquet is not designed to flicker your screen at 250 fps or whatever just so you can say "my graphics card is fast". It actually limits the framerate, so that other computational tasks you might run are allowed to run, and if those are quiet, the framerate is NOT increased. Some video gamers focus on framerate as their model of systems performance. That really seems irrelevant to Croquet. But if you want a higher framerate, just find the scheduling of the redraw task, and set it to run at a high framerate. You may not be able to do anything else, but you'll have your eyecandy and bragging rights. Derek Arndt wrote: > Thanks John, > > I'm coming back to this specific issue as I would like to have a > better understanding of where the framerate is going. With many > optimized objects in the scene I am unable to obtain an acceptable > framerate and I can't help but feel I'm being limited by the rate of > which key methods are being fired in squeak. > > I've adjusted the configuration in the plist without any noticeable > results. Below is a link to the shark profile - I'm not used to > reading much outside of the application's symbols (and because this > code isn't a C the results aren't very useful for the app itself). > I'm interested to see what you can gleam from the profile if anything: > > http://img409.imageshack.us/my.php?image=picture1hj4.png > > Interestingly enabling higherPerformance doesn't change the low > framerate when rendering many objects on screen (which I would take to > mean the bottleneck is in rendering the objects - but the framerates > are much less then I would expect) > > Thanks for your time John, > Derek > > On Jul 20, 2007, at 10:46 AM, Peter Moore wrote: > >> >>> *From: *John M McIntosh <[hidden email] >>> <mailto:[hidden email]>> >>> *Date: *June 12, 2007 3:21:01 AM CDT >>> *To: *[hidden email] <mailto:[hidden email]>, Derek >>> Arndt <[hidden email] <mailto:[hidden email]>> >>> *Subject: **Re: [croquet-dev] Rendering Performance* >>> *Reply-To: *[hidden email] <mailto:[hidden email]>, John >>> M McIntosh <[hidden email] >>> <mailto:[hidden email]>> >>> >>> Derek I've never looked at the Open/GL croquet drawing with >>> relationship to the squeak displayscreen drawing. If you are using >>> the carbon macintosh vm, there are some info.plist parms see >>> http://www.smalltalkconsulting.com/html/squeakinfoplist.html say >>> SqueakUIFlushPrimaryDeferNMilliseconds which affect drawing >>> performance for the non open/gl stuff. >>> >>> Use of Apple's Shark should tell you where the time is going, and >>> how much clock time is used sitting in the VM is sleeping primitive. >>> >>> On Jun 8, 2007, at 1:11 PM, Derek Arndt wrote: >>> >>>> Hey everyone - this is my first time posting to the list. >>>> I've been a Mac shareware game developer for a number of years at >>>> http://www.batteryacid.org and now I'm jumping straight into croquet. >>>> >>>> One of the first things to strike me that I haven't been able to >>>> improve is the low framerate. In the simplest of demos I'm >>>> experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, >>>> almost zero vertices or fragments on the screen). I've spent some >>>> time using the popular debugging tools and experimenting by >>>> rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: >>>> and reducing the large number of GL state changes submitted to the >>>> driver. >>>> >>>> Sure it's easy to find obvious places of graphical improvement, but >>>> getting little improvement and not finding a clear graphical >>>> bottleneck leads me to think there is other limiting in place (or >>>> timers that specify how often to render). Is this correct? >>>> >>>> Thanks for your time, >>>> Derek Arndt >>>> >>>> PS. Does croquet have VBL syncing? >>> >>> -- >>> =========================================================================== >>> John M. McIntosh <[hidden email] >>> <mailto:[hidden email]>> >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >> > |
|
|
In reply to this post by Derek Arndt
Perhaps I was a little harsh in the way I responded, but 42 fps is
pretty much reasonable for human interactive performance... which is why the Croquet scheduler runs rendering at such rates. |
|
|
Hi David,
The real problem is when you have a complex scene and the framerate drops below say 10. 42 fps would be more than sufficient (I would be happy with a steady 25 fps), but when that is the ceiling for even a modest scene the framerate rapidly decreases as more geometry is added. This is the case even with highly optimized rendering code using the GPU for all of the heavy lifting. -Peter On Jul 20, 2007, at 5:34 PM, David P. Reed wrote: > Perhaps I was a little harsh in the way I responded, but 42 fps is > pretty much reasonable for human interactive performance... which > is why the Croquet scheduler runs rendering at such rates. > |
|
|
In reply to this post by David P. Reed
> 42 fps is pretty much reasonable for human interactive performance would that I could get such a rate on my 2GHz iMac -- still on 5-10fps, which is nearly page-turning rate. 'higher performance' and plist parameters make no obvious difference. 24fps would be acceptable to me. |
|
|
Given that the profile shows that 55% of real time is spent sleeping in
the Squeak idle loop (meaning that Squeak thinks there is nothing to do) this is not caused by a slow processor. As I noted, Croquet does try to limit how frequently the renderer runs, but perhaps someone has actually coded a "sleep" or blocking i/o operation into a method somewhere while a lock is being held by that Squeak thread, or in the middle of a Croquet operation? One should never do that. But a programmer unfamiliar with the Croquet programming enviroment might have done so. All networking and other I/O should be non-blocking, and sleeping should never be done in Croquet code. That's what messages are for. matthew chadwick wrote: > >> 42 fps is pretty much reasonable for human interactive performance > > > would that I could get such a rate on my 2GHz iMac -- still on > 5-10fps, which is nearly page-turning rate. 'higher performance' and > plist parameters make no obvious difference. 24fps would be acceptable > to me. > |
|
|
sure but I'm running the demos which came with Croquet1.0.18. Naturally
I'm running Croquet exclusively. The fps drops by a consistant 5fps during accerations but returns to the high value under constant velocity. I noticed that the newer demos (the sailing one for example) run faster, around 20fps, than the older ones. Anyway, this fps talk is I agree largely beside the point; Croquet is far bigger than this number :-] David P. Reed wrote: > Given that the profile shows that 55% of real time is spent sleeping > in the Squeak idle loop (meaning that Squeak thinks there is nothing > to do) this is not caused by a slow processor. As I noted, Croquet > does try to limit how frequently the renderer runs, but perhaps > someone has actually coded a "sleep" or blocking i/o operation into a > method somewhere while a lock is being held by that Squeak thread, or > in the middle of a Croquet operation? > > One should never do that. But a programmer unfamiliar with the > Croquet programming enviroment might have done so. All networking > and other I/O should be non-blocking, and sleeping should never be > done in Croquet code. That's what messages are for. > > matthew chadwick wrote: > >> >>> 42 fps is pretty much reasonable for human interactive performance >> >> >> >> would that I could get such a rate on my 2GHz iMac -- still on >> 5-10fps, which is nearly page-turning rate. 'higher performance' and >> plist parameters make no obvious difference. 24fps would be >> acceptable to me. >> > |
|
|
On Jul 20, 2007, at 11:11 PM, matthew chadwick wrote:
> sure but I'm running the demos which came with Croquet1.0.18. > Naturally I'm running Croquet exclusively. The fps drops by a > consistant 5fps during accerations but returns to the high value > under constant velocity. I noticed that the newer demos (the > sailing one for example) run faster, around 20fps, than the older > ones. > > Anyway, this fps talk is I agree largely beside the point; Croquet > is far bigger than this number :-] The fps is nothing more than a way of describing quantitatively how interactive and responsive a Croquet simulation is. This isn't about how we can achieve 120 fps on the latest Nvidia card. Croquet is much more than a 3D engine. I get it. > > David P. Reed wrote: > >> Given that the profile shows that 55% of real time is spent >> sleeping in the Squeak idle loop (meaning that Squeak thinks there >> is nothing to do) this is not caused by a slow processor. As I >> noted, Croquet does try to limit how frequently the renderer runs, >> but perhaps someone has actually coded a "sleep" or blocking i/o >> operation into a method somewhere while a lock is being held by >> that Squeak thread, or in the middle of a Croquet operation? >> >> One should never do that. But a programmer unfamiliar with the >> Croquet programming enviroment might have done so. All >> networking and other I/O should be non-blocking, and sleeping >> should never be done in Croquet code. That's what messages are for. >> >> matthew chadwick wrote: >> >>> >>>> 42 fps is pretty much reasonable for human interactive performance >>> >>> >>> >>> would that I could get such a rate on my 2GHz iMac -- still on >>> 5-10fps, which is nearly page-turning rate. 'higher performance' >>> and plist parameters make no obvious difference. 24fps would be >>> acceptable to me. >>> >> |
|
|
In reply to this post by David P. Reed
Hey David,
Thanks for the confirmation of my suspicions. Like any serious graphics application it's not about achieving the highest framerate (VBL sync takes care of limiting the CPU and GPU nicely) but to rather be able to throw as much on the screen and still achieve an experience that's not a slideshow (250FPS works while 2.50FPS doesn't). The technologies and techniques I'm currently using have been around since the early part of this decade and with this small amount of action in Croquet the framerate is unacceptable. I spent a few minutes tracing through the render routines to try and find the scheduler limiting to play around (who knows, maybe I'll find out from this further profiling I'm doing something horribly wrong, the more I can understand the better though) - so far no luck. Could you point me in the right direction or give me some quick insight into where I should be looking? Thanks again - I appreciate your time, Derek On Jul 20, 2007, at 5:26 PM, David P. Reed wrote: > You are not bottlenecked by Squeak, but instead are idle. And the > reason is quite simple, I suspect. Croquet is not designed to > flicker your screen at 250 fps or whatever just so you can say "my > graphics card is fast". It actually limits the framerate, so that > other computational tasks you might run are allowed to run, and if > those are quiet, the framerate is NOT increased. > > Some video gamers focus on framerate as their model of systems > performance. That really seems irrelevant to Croquet. But if you > want a higher framerate, just find the scheduling of the redraw > task, and set it to run at a high framerate. You may not be able > to do anything else, but you'll have your eyecandy and bragging > rights. > > > Derek Arndt wrote: >> Thanks John, >> >> I'm coming back to this specific issue as I would like to have a >> better understanding of where the framerate is going. With many >> optimized objects in the scene I am unable to obtain an acceptable >> framerate and I can't help but feel I'm being limited by the rate >> of which key methods are being fired in squeak. >> >> I've adjusted the configuration in the plist without any >> noticeable results. Below is a link to the shark profile - I'm >> not used to reading much outside of the application's symbols (and >> because this code isn't a C the results aren't very useful for the >> app itself). I'm interested to see what you can gleam from the >> profile if anything: >> >> http://img409.imageshack.us/my.php?image=picture1hj4.png >> >> Interestingly enabling higherPerformance doesn't change the low >> framerate when rendering many objects on screen (which I would >> take to mean the bottleneck is in rendering the objects - but the >> framerates are much less then I would expect) >> >> Thanks for your time John, >> Derek >> >> On Jul 20, 2007, at 10:46 AM, Peter Moore wrote: >> >>> >>>> *From: *John M McIntosh <[hidden email] >>>> <mailto:[hidden email]>> >>>> *Date: *June 12, 2007 3:21:01 AM CDT >>>> *To: *[hidden email] <mailto:[hidden email]>, Derek >>>> Arndt <[hidden email] <mailto:[hidden email]>> >>>> *Subject: **Re: [croquet-dev] Rendering Performance* >>>> *Reply-To: *[hidden email] <mailto:[hidden email]>, >>>> John M McIntosh <[hidden email] >>>> <mailto:[hidden email]>> >>>> >>>> Derek I've never looked at the Open/GL croquet drawing with >>>> relationship to the squeak displayscreen drawing. If you are >>>> using the carbon macintosh vm, there are some info.plist parms >>>> see http://www.smalltalkconsulting.com/html/ >>>> squeakinfoplist.html say >>>> SqueakUIFlushPrimaryDeferNMilliseconds which affect drawing >>>> performance for the non open/gl stuff. >>>> >>>> Use of Apple's Shark should tell you where the time is going, >>>> and how much clock time is used sitting in the VM is sleeping >>>> primitive. >>>> >>>> On Jun 8, 2007, at 1:11 PM, Derek Arndt wrote: >>>> >>>>> Hey everyone - this is my first time posting to the list. >>>>> I've been a Mac shareware game developer for a number of years >>>>> at http://www.batteryacid.org and now I'm jumping straight into >>>>> croquet. >>>>> >>>>> One of the first things to strike me that I haven't been able >>>>> to improve is the low framerate. In the simplest of demos I'm >>>>> experiencing a maximum of 42FPS on a MacBook Pro (CPU not >>>>> pegged, almost zero vertices or fragments on the screen). I've >>>>> spent some time using the popular debugging tools and >>>>> experimenting by rendering nothing in TSpace -> >>>>> RenderSpace:port:depth:ghostFrame: and reducing the large >>>>> number of GL state changes submitted to the driver. >>>>> >>>>> Sure it's easy to find obvious places of graphical improvement, >>>>> but getting little improvement and not finding a clear >>>>> graphical bottleneck leads me to think there is other limiting >>>>> in place (or timers that specify how often to render). Is this >>>>> correct? >>>>> >>>>> Thanks for your time, >>>>> Derek Arndt >>>>> >>>>> PS. Does croquet have VBL syncing? >>>> >>>> -- >>>> =================================================================== >>>> ======== >>>> John M. McIntosh <[hidden email] >>>> <mailto:[hidden email]>> >>>> Corporate Smalltalk Consulting Ltd. http:// >>>> www.smalltalkconsulting.com >>>> =================================================================== >>>> ======== >>>> >>>> >>> >> |
|
|
Derek - I confess that I haven't been tracking the current code body,
since my focus is on researching a next generation of TeaTime. But each rendering pass schedules the next one by doing a future:send: operation to render the space. How the delay till the next rendering is calculated is presumably still calculated in an adaptive manner, taking into account a variety of performance measures, like how far behind the current rendering is from real time. There is one other thing that could be a systemic problem, which relates to how the Squeak VM you are using decides to sleep. When there is nothing for Squeak to do, it tells the operating system it wants to sleep. Now in ancient systems (MacOS and some Unixes/Linuxes) the sleeping function in a process has a very poor time resolving capability - typically you sleep waiting for either an interrupt or an I/O transition into the process, or an elapsed time. On Unix, this is a select() or a poll() operation. When rendering says "run the render step again in 20 msec." it does no good if what happens is that the Squeak VM runs out of things to do and sleeps in the OS using a call that cannot respond in less than 50 msec. The next render step won't happen soon enough. Squeak's VM has had a variety of kludges put in to deal with that, and since there are many hands in the Squeak VM, this often breaks. I have had to put in a fix for this kind of thing in the past because the network driver wasn't propery prioritizing wakeups to pull the machine out of sleeping. I think that fix is still in there and correct. But a VM maintainer might want to look at that also. Derek Arndt wrote: > Hey David, > > Thanks for the confirmation of my suspicions. Like any serious > graphics application it's not about achieving the highest framerate > (VBL sync takes care of limiting the CPU and GPU nicely) but to rather > be able to throw as much on the screen and still achieve an experience > that's not a slideshow (250FPS works while 2.50FPS doesn't). The > technologies and techniques I'm currently using have been around since > the early part of this decade and with this small amount of action in > Croquet the framerate is unacceptable. > > I spent a few minutes tracing through the render routines to try and > find the scheduler limiting to play around (who knows, maybe I'll find > out from this further profiling I'm doing something horribly wrong, > the more I can understand the better though) - so far no luck. Could > you point me in the right direction or give me some quick insight into > where I should be looking? > > Thanks again - I appreciate your time, > Derek > > On Jul 20, 2007, at 5:26 PM, David P. Reed wrote: > >> You are not bottlenecked by Squeak, but instead are idle. And the >> reason is quite simple, I suspect. Croquet is not designed to >> flicker your screen at 250 fps or whatever just so you can say "my >> graphics card is fast". It actually limits the framerate, so that >> other computational tasks you might run are allowed to run, and if >> those are quiet, the framerate is NOT increased. >> >> Some video gamers focus on framerate as their model of systems >> performance. That really seems irrelevant to Croquet. But if you >> want a higher framerate, just find the scheduling of the redraw task, >> and set it to run at a high framerate. You may not be able to do >> anything else, but you'll have your eyecandy and bragging rights. >> >> >> Derek Arndt wrote: >>> Thanks John, >>> >>> I'm coming back to this specific issue as I would like to have a >>> better understanding of where the framerate is going. With many >>> optimized objects in the scene I am unable to obtain an acceptable >>> framerate and I can't help but feel I'm being limited by the rate of >>> which key methods are being fired in squeak. >>> >>> I've adjusted the configuration in the plist without any noticeable >>> results. Below is a link to the shark profile - I'm not used to >>> reading much outside of the application's symbols (and because this >>> code isn't a C the results aren't very useful for the app itself). >>> I'm interested to see what you can gleam from the profile if anything: >>> >>> http://img409.imageshack.us/my.php?image=picture1hj4.png >>> >>> Interestingly enabling higherPerformance doesn't change the low >>> framerate when rendering many objects on screen (which I would take >>> to mean the bottleneck is in rendering the objects - but the >>> framerates are much less then I would expect) >>> >>> Thanks for your time John, >>> Derek >>> >>> On Jul 20, 2007, at 10:46 AM, Peter Moore wrote: >>> >>>> >>>>> *From: *John M McIntosh <[hidden email] >>>>> <mailto:[hidden email]>> >>>>> *Date: *June 12, 2007 3:21:01 AM CDT >>>>> *To: *[hidden email] <mailto:[hidden email]>, Derek >>>>> Arndt <[hidden email] <mailto:[hidden email]>> >>>>> *Subject: **Re: [croquet-dev] Rendering Performance* >>>>> *Reply-To: *[hidden email] <mailto:[hidden email]>, >>>>> John M McIntosh <[hidden email] >>>>> <mailto:[hidden email]>> >>>>> >>>>> Derek I've never looked at the Open/GL croquet drawing with >>>>> relationship to the squeak displayscreen drawing. If you are using >>>>> the carbon macintosh vm, there are some info.plist parms see >>>>> http://www.smalltalkconsulting.com/html/squeakinfoplist.html say >>>>> SqueakUIFlushPrimaryDeferNMilliseconds which affect drawing >>>>> performance for the non open/gl stuff. >>>>> >>>>> Use of Apple's Shark should tell you where the time is going, and >>>>> how much clock time is used sitting in the VM is sleeping primitive. >>>>> >>>>> On Jun 8, 2007, at 1:11 PM, Derek Arndt wrote: >>>>> >>>>>> Hey everyone - this is my first time posting to the list. >>>>>> I've been a Mac shareware game developer for a number of years at >>>>>> http://www.batteryacid.org and now I'm jumping straight into >>>>>> croquet. >>>>>> >>>>>> One of the first things to strike me that I haven't been able to >>>>>> improve is the low framerate. In the simplest of demos I'm >>>>>> experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, >>>>>> almost zero vertices or fragments on the screen). I've spent >>>>>> some time using the popular debugging tools and experimenting by >>>>>> rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: >>>>>> and reducing the large number of GL state changes submitted to >>>>>> the driver. >>>>>> >>>>>> Sure it's easy to find obvious places of graphical improvement, >>>>>> but getting little improvement and not finding a clear graphical >>>>>> bottleneck leads me to think there is other limiting in place (or >>>>>> timers that specify how often to render). Is this correct? >>>>>> >>>>>> Thanks for your time, >>>>>> Derek Arndt >>>>>> >>>>>> PS. Does croquet have VBL syncing? >>>>> >>>>> -- >>>>> =========================================================================== >>>>> >>>>> John M. McIntosh <[hidden email] >>>>> <mailto:[hidden email]>> >>>>> Corporate Smalltalk Consulting Ltd. >>>>> http://www.smalltalkconsulting.com >>>>> =========================================================================== >>>>> >>>>> >>>>> >>>> >>> > > |
|
|
Hey Derek,
Ok I admit I'm only just scanning these emails but I have to ask the question: Why in the world would you need 250 fps? When I was 6 years old I worked at an animation camera company across from Hannah Barbara. At the time the cameramen were up in arms because standard cartoons were going from 12 to 7 fps. The cameramen were arguing that 7 fps was too slow and would show a flicker (the cartoons looked fine to me, I think they were upset about the money they were loosing doing the shooting). From my time working in the movie business later I know that most films are like 25 fps. When you see someone running on a movie screen they don't look like they are jumping from place to place. There is no way the human eye could discern 250 fps. A frame rate of 12 is really good, 25 is excellent, 250 is nuts. Am I missing something? Ron > -----Original Message----- > From: David P. Reed [mailto:[hidden email]] > Sent: Monday, July 23, 2007 2:03 PM > To: [hidden email]; Derek Arndt > Subject: Re: [croquet-dev] Rendering Performance > > Derek - I confess that I haven't been tracking the current code body, > since my focus is on researching a next generation of TeaTime. But > each rendering pass schedules the next one by doing a future:send: > operation to render the space. How the delay till the next rendering > is calculated is presumably still calculated in an adaptive manner, > taking into account a variety of performance measures, like how far > behind the current rendering is from real time. > > There is one other thing that could be a systemic problem, which relates > to how the Squeak VM you are using decides to sleep. When there is > nothing for Squeak to do, it tells the operating system it wants to > sleep. Now in ancient systems (MacOS and some Unixes/Linuxes) the > sleeping function in a process has a very poor time resolving capability > - typically you sleep waiting for either an interrupt or an I/O > transition into the process, or an elapsed time. On Unix, this is a > select() or a poll() operation. > > When rendering says "run the render step again in 20 msec." it does no > good if what happens is that the Squeak VM runs out of things to do and > sleeps in the OS using a call that cannot respond in less than 50 > msec. The next render step won't happen soon enough. Squeak's VM has > had a variety of kludges put in to deal with that, and since there are > many hands in the Squeak VM, this often breaks. > > I have had to put in a fix for this kind of thing in the past because > the network driver wasn't propery prioritizing wakeups to pull the > machine out of sleeping. I think that fix is still in there and > correct. But a VM maintainer might want to look at that also. > > > > > Derek Arndt wrote: > > Hey David, > > > > Thanks for the confirmation of my suspicions. Like any serious > > graphics application it's not about achieving the highest framerate > > (VBL sync takes care of limiting the CPU and GPU nicely) but to rather > > be able to throw as much on the screen and still achieve an experience > > that's not a slideshow (250FPS works while 2.50FPS doesn't). The > > technologies and techniques I'm currently using have been around since > > the early part of this decade and with this small amount of action in > > Croquet the framerate is unacceptable. > > > > I spent a few minutes tracing through the render routines to try and > > find the scheduler limiting to play around (who knows, maybe I'll find > > out from this further profiling I'm doing something horribly wrong, > > the more I can understand the better though) - so far no luck. Could > > you point me in the right direction or give me some quick insight into > > where I should be looking? > > > > Thanks again - I appreciate your time, > > Derek > > > > On Jul 20, 2007, at 5:26 PM, David P. Reed wrote: > > > >> You are not bottlenecked by Squeak, but instead are idle. And the > >> reason is quite simple, I suspect. Croquet is not designed to > >> flicker your screen at 250 fps or whatever just so you can say "my > >> graphics card is fast". It actually limits the framerate, so that > >> other computational tasks you might run are allowed to run, and if > >> those are quiet, the framerate is NOT increased. > >> > >> Some video gamers focus on framerate as their model of systems > >> performance. That really seems irrelevant to Croquet. But if you > >> want a higher framerate, just find the scheduling of the redraw task, > >> and set it to run at a high framerate. You may not be able to do > >> anything else, but you'll have your eyecandy and bragging rights. > >> > >> > >> Derek Arndt wrote: > >>> Thanks John, > >>> > >>> I'm coming back to this specific issue as I would like to have a > >>> better understanding of where the framerate is going. With many > >>> optimized objects in the scene I am unable to obtain an acceptable > >>> framerate and I can't help but feel I'm being limited by the rate of > >>> which key methods are being fired in squeak. > >>> > >>> I've adjusted the configuration in the plist without any noticeable > >>> results. Below is a link to the shark profile - I'm not used to > >>> reading much outside of the application's symbols (and because this > >>> code isn't a C the results aren't very useful for the app itself). > >>> I'm interested to see what you can gleam from the profile if anything: > >>> > >>> http://img409.imageshack.us/my.php?image=picture1hj4.png > >>> > >>> Interestingly enabling higherPerformance doesn't change the low > >>> framerate when rendering many objects on screen (which I would take > >>> to mean the bottleneck is in rendering the objects - but the > >>> framerates are much less then I would expect) > >>> > >>> Thanks for your time John, > >>> Derek > >>> > >>> On Jul 20, 2007, at 10:46 AM, Peter Moore wrote: > >>> > >>>> > >>>>> *From: *John M McIntosh <[hidden email] > >>>>> <mailto:[hidden email]>> > >>>>> *Date: *June 12, 2007 3:21:01 AM CDT > >>>>> *To: *[hidden email] <mailto:[hidden email]>, Derek > >>>>> Arndt <[hidden email] <mailto:[hidden email]>> > >>>>> *Subject: **Re: [croquet-dev] Rendering Performance* > >>>>> *Reply-To: *[hidden email] <mailto:[hidden email]>, > >>>>> John M McIntosh <[hidden email] > >>>>> <mailto:[hidden email]>> > >>>>> > >>>>> Derek I've never looked at the Open/GL croquet drawing with > >>>>> relationship to the squeak displayscreen drawing. If you are using > >>>>> the carbon macintosh vm, there are some info.plist parms see > >>>>> http://www.smalltalkconsulting.com/html/squeakinfoplist.html say > >>>>> SqueakUIFlushPrimaryDeferNMilliseconds which affect drawing > >>>>> performance for the non open/gl stuff. > >>>>> > >>>>> Use of Apple's Shark should tell you where the time is going, and > >>>>> how much clock time is used sitting in the VM is sleeping primitive. > >>>>> > >>>>> On Jun 8, 2007, at 1:11 PM, Derek Arndt wrote: > >>>>> > >>>>>> Hey everyone - this is my first time posting to the list. > >>>>>> I've been a Mac shareware game developer for a number of years at > >>>>>> http://www.batteryacid.org and now I'm jumping straight into > >>>>>> croquet. > >>>>>> > >>>>>> One of the first things to strike me that I haven't been able to > >>>>>> improve is the low framerate. In the simplest of demos I'm > >>>>>> experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, > >>>>>> almost zero vertices or fragments on the screen). I've spent > >>>>>> some time using the popular debugging tools and experimenting by > >>>>>> rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: > >>>>>> and reducing the large number of GL state changes submitted to > >>>>>> the driver. > >>>>>> > >>>>>> Sure it's easy to find obvious places of graphical improvement, > >>>>>> but getting little improvement and not finding a clear graphical > >>>>>> bottleneck leads me to think there is other limiting in place (or > >>>>>> timers that specify how often to render). Is this correct? > >>>>>> > >>>>>> Thanks for your time, > >>>>>> Derek Arndt > >>>>>> > >>>>>> PS. Does croquet have VBL syncing? > >>>>> > >>>>> -- > >>>>> > ========================================================================== > = > >>>>> > >>>>> John M. McIntosh <[hidden email] > >>>>> <mailto:[hidden email]>> > >>>>> Corporate Smalltalk Consulting Ltd. > >>>>> http://www.smalltalkconsulting.com > >>>>> > ========================================================================== > = > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > > |
|
|
Actually, frame rates of 120 Hz re often used for flicker free stereo
rendering using crystal shutter glasses. This is 60 Hz for each eye. That does not necessarily mean that the graphics will or can run that fast, but the display hardware will certainly support it if it does. David Ron Teitelbaum wrote: > Hey Derek, > > Ok I admit I'm only just scanning these emails but I have to ask the > question: Why in the world would you need 250 fps? When I was 6 years old I > worked at an animation camera company across from Hannah Barbara. At the > time the cameramen were up in arms because standard cartoons were going from > 12 to 7 fps. The cameramen were arguing that 7 fps was too slow and would > show a flicker (the cartoons looked fine to me, I think they were upset > about the money they were loosing doing the shooting). From my time working > in the movie business later I know that most films are like 25 fps. When > you see someone running on a movie screen they don't look like they are > jumping from place to place. There is no way the human eye could discern > 250 fps. > > A frame rate of 12 is really good, 25 is excellent, 250 is nuts. > > Am I missing something? > > Ron > > >> -----Original Message----- >> From: David P. Reed [mailto:[hidden email]] >> Sent: Monday, July 23, 2007 2:03 PM >> To: [hidden email]; Derek Arndt >> Subject: Re: [croquet-dev] Rendering Performance >> >> Derek - I confess that I haven't been tracking the current code body, >> since my focus is on researching a next generation of TeaTime. But >> each rendering pass schedules the next one by doing a future:send: >> operation to render the space. How the delay till the next rendering >> is calculated is presumably still calculated in an adaptive manner, >> taking into account a variety of performance measures, like how far >> behind the current rendering is from real time. >> >> There is one other thing that could be a systemic problem, which relates >> to how the Squeak VM you are using decides to sleep. When there is >> nothing for Squeak to do, it tells the operating system it wants to >> sleep. Now in ancient systems (MacOS and some Unixes/Linuxes) the >> sleeping function in a process has a very poor time resolving capability >> - typically you sleep waiting for either an interrupt or an I/O >> transition into the process, or an elapsed time. On Unix, this is a >> select() or a poll() operation. >> >> When rendering says "run the render step again in 20 msec." it does no >> good if what happens is that the Squeak VM runs out of things to do and >> sleeps in the OS using a call that cannot respond in less than 50 >> msec. The next render step won't happen soon enough. Squeak's VM has >> had a variety of kludges put in to deal with that, and since there are >> many hands in the Squeak VM, this often breaks. >> >> I have had to put in a fix for this kind of thing in the past because >> the network driver wasn't propery prioritizing wakeups to pull the >> machine out of sleeping. I think that fix is still in there and >> correct. But a VM maintainer might want to look at that also. >> >> >> >> >> Derek Arndt wrote: >> >>> Hey David, >>> >>> Thanks for the confirmation of my suspicions. Like any serious >>> graphics application it's not about achieving the highest framerate >>> (VBL sync takes care of limiting the CPU and GPU nicely) but to rather >>> be able to throw as much on the screen and still achieve an experience >>> that's not a slideshow (250FPS works while 2.50FPS doesn't). The >>> technologies and techniques I'm currently using have been around since >>> the early part of this decade and with this small amount of action in >>> Croquet the framerate is unacceptable. >>> >>> I spent a few minutes tracing through the render routines to try and >>> find the scheduler limiting to play around (who knows, maybe I'll find >>> out from this further profiling I'm doing something horribly wrong, >>> the more I can understand the better though) - so far no luck. Could >>> you point me in the right direction or give me some quick insight into >>> where I should be looking? >>> >>> Thanks again - I appreciate your time, >>> Derek >>> >>> On Jul 20, 2007, at 5:26 PM, David P. Reed wrote: >>> >>> >>>> You are not bottlenecked by Squeak, but instead are idle. And the >>>> reason is quite simple, I suspect. Croquet is not designed to >>>> flicker your screen at 250 fps or whatever just so you can say "my >>>> graphics card is fast". It actually limits the framerate, so that >>>> other computational tasks you might run are allowed to run, and if >>>> those are quiet, the framerate is NOT increased. >>>> >>>> Some video gamers focus on framerate as their model of systems >>>> performance. That really seems irrelevant to Croquet. But if you >>>> want a higher framerate, just find the scheduling of the redraw task, >>>> and set it to run at a high framerate. You may not be able to do >>>> anything else, but you'll have your eyecandy and bragging rights. >>>> >>>> >>>> Derek Arndt wrote: >>>> >>>>> Thanks John, >>>>> >>>>> I'm coming back to this specific issue as I would like to have a >>>>> better understanding of where the framerate is going. With many >>>>> optimized objects in the scene I am unable to obtain an acceptable >>>>> framerate and I can't help but feel I'm being limited by the rate of >>>>> which key methods are being fired in squeak. >>>>> >>>>> I've adjusted the configuration in the plist without any noticeable >>>>> results. Below is a link to the shark profile - I'm not used to >>>>> reading much outside of the application's symbols (and because this >>>>> code isn't a C the results aren't very useful for the app itself). >>>>> I'm interested to see what you can gleam from the profile if anything: >>>>> >>>>> http://img409.imageshack.us/my.php?image=picture1hj4.png >>>>> >>>>> Interestingly enabling higherPerformance doesn't change the low >>>>> framerate when rendering many objects on screen (which I would take >>>>> to mean the bottleneck is in rendering the objects - but the >>>>> framerates are much less then I would expect) >>>>> >>>>> Thanks for your time John, >>>>> Derek >>>>> >>>>> On Jul 20, 2007, at 10:46 AM, Peter Moore wrote: >>>>> >>>>> >>>>>>> *From: *John M McIntosh <[hidden email] >>>>>>> <mailto:[hidden email]>> >>>>>>> *Date: *June 12, 2007 3:21:01 AM CDT >>>>>>> *To: *[hidden email] <mailto:[hidden email]>, Derek >>>>>>> Arndt <[hidden email] <mailto:[hidden email]>> >>>>>>> *Subject: **Re: [croquet-dev] Rendering Performance* >>>>>>> *Reply-To: *[hidden email] <mailto:[hidden email]>, >>>>>>> John M McIntosh <[hidden email] >>>>>>> <mailto:[hidden email]>> >>>>>>> >>>>>>> Derek I've never looked at the Open/GL croquet drawing with >>>>>>> relationship to the squeak displayscreen drawing. If you are using >>>>>>> the carbon macintosh vm, there are some info.plist parms see >>>>>>> http://www.smalltalkconsulting.com/html/squeakinfoplist.html say >>>>>>> SqueakUIFlushPrimaryDeferNMilliseconds which affect drawing >>>>>>> performance for the non open/gl stuff. >>>>>>> >>>>>>> Use of Apple's Shark should tell you where the time is going, and >>>>>>> how much clock time is used sitting in the VM is sleeping primitive. >>>>>>> >>>>>>> On Jun 8, 2007, at 1:11 PM, Derek Arndt wrote: >>>>>>> >>>>>>> >>>>>>>> Hey everyone - this is my first time posting to the list. >>>>>>>> I've been a Mac shareware game developer for a number of years at >>>>>>>> http://www.batteryacid.org and now I'm jumping straight into >>>>>>>> croquet. >>>>>>>> >>>>>>>> One of the first things to strike me that I haven't been able to >>>>>>>> improve is the low framerate. In the simplest of demos I'm >>>>>>>> experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, >>>>>>>> almost zero vertices or fragments on the screen). I've spent >>>>>>>> some time using the popular debugging tools and experimenting by >>>>>>>> rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: >>>>>>>> and reducing the large number of GL state changes submitted to >>>>>>>> the driver. >>>>>>>> >>>>>>>> Sure it's easy to find obvious places of graphical improvement, >>>>>>>> but getting little improvement and not finding a clear graphical >>>>>>>> bottleneck leads me to think there is other limiting in place (or >>>>>>>> timers that specify how often to render). Is this correct? >>>>>>>> >>>>>>>> Thanks for your time, >>>>>>>> Derek Arndt >>>>>>>> >>>>>>>> PS. Does croquet have VBL syncing? >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >> ========================================================================== >> = >> >>>>>>> John M. McIntosh <[hidden email] >>>>>>> <mailto:[hidden email]>> >>>>>>> Corporate Smalltalk Consulting Ltd. >>>>>>> http://www.smalltalkconsulting.com >>>>>>> >>>>>>> >> ========================================================================== >> = >> >>>>>>> >>>>>>> >>> > > |
|
|
Hi David,
That sounds really cool. Does it really have separate frames for each flash? I thought that there were multiple flashes per frame. (like the gate on a projector which actually opens and closes multiple times per frame). Isn't the frame rate a multiple of the refresh rate? I figured the Hz refresh rate was a different issue that happened automatically from the settings of the card. Ron > -----Original Message----- > From: David A Smith [mailto:[hidden email]] > Sent: Monday, July 23, 2007 7:22 PM > To: [hidden email]; Ron Teitelbaum > Cc: 'David P. Reed'; 'Derek Arndt' > Subject: Re: [croquet-dev] Rendering Performance > > Actually, frame rates of 120 Hz re often used for flicker free stereo > rendering using crystal shutter glasses. This is 60 Hz for each eye. > That does not necessarily mean that the graphics will or can run that > fast, but the display hardware will certainly support it if it does. > > David > > > Ron Teitelbaum wrote: > > Hey Derek, > > > > Ok I admit I'm only just scanning these emails but I have to ask the > > question: Why in the world would you need 250 fps? When I was 6 years > old I > > worked at an animation camera company across from Hannah Barbara. At > the > > time the cameramen were up in arms because standard cartoons were going > from > > 12 to 7 fps. The cameramen were arguing that 7 fps was too slow and > would > > show a flicker (the cartoons looked fine to me, I think they were upset > > about the money they were loosing doing the shooting). From my time > working > > in the movie business later I know that most films are like 25 fps. > When > > you see someone running on a movie screen they don't look like they are > > jumping from place to place. There is no way the human eye could > discern > > 250 fps. > > > > A frame rate of 12 is really good, 25 is excellent, 250 is nuts. > > > > Am I missing something? > > > > Ron > > > > > >> -----Original Message----- > >> From: David P. Reed [mailto:[hidden email]] > >> Sent: Monday, July 23, 2007 2:03 PM > >> To: [hidden email]; Derek Arndt > >> Subject: Re: [croquet-dev] Rendering Performance > >> > >> Derek - I confess that I haven't been tracking the current code body, > >> since my focus is on researching a next generation of TeaTime. But > >> each rendering pass schedules the next one by doing a future:send: > >> operation to render the space. How the delay till the next rendering > >> is calculated is presumably still calculated in an adaptive manner, > >> taking into account a variety of performance measures, like how far > >> behind the current rendering is from real time. > >> > >> There is one other thing that could be a systemic problem, which > relates > >> to how the Squeak VM you are using decides to sleep. When there is > >> nothing for Squeak to do, it tells the operating system it wants to > >> sleep. Now in ancient systems (MacOS and some Unixes/Linuxes) the > >> sleeping function in a process has a very poor time resolving > capability > >> - typically you sleep waiting for either an interrupt or an I/O > >> transition into the process, or an elapsed time. On Unix, this is a > >> select() or a poll() operation. > >> > >> When rendering says "run the render step again in 20 msec." it does no > >> good if what happens is that the Squeak VM runs out of things to do and > >> sleeps in the OS using a call that cannot respond in less than 50 > >> msec. The next render step won't happen soon enough. Squeak's VM > has > >> had a variety of kludges put in to deal with that, and since there are > >> many hands in the Squeak VM, this often breaks. > >> > >> I have had to put in a fix for this kind of thing in the past because > >> the network driver wasn't propery prioritizing wakeups to pull the > >> machine out of sleeping. I think that fix is still in there and > >> correct. But a VM maintainer might want to look at that also. > >> > >> > >> > >> > >> Derek Arndt wrote: > >> > >>> Hey David, > >>> > >>> Thanks for the confirmation of my suspicions. Like any serious > >>> graphics application it's not about achieving the highest framerate > >>> (VBL sync takes care of limiting the CPU and GPU nicely) but to rather > >>> be able to throw as much on the screen and still achieve an experience > >>> that's not a slideshow (250FPS works while 2.50FPS doesn't). The > >>> technologies and techniques I'm currently using have been around since > >>> the early part of this decade and with this small amount of action in > >>> Croquet the framerate is unacceptable. > >>> > >>> I spent a few minutes tracing through the render routines to try and > >>> find the scheduler limiting to play around (who knows, maybe I'll find > >>> out from this further profiling I'm doing something horribly wrong, > >>> the more I can understand the better though) - so far no luck. Could > >>> you point me in the right direction or give me some quick insight into > >>> where I should be looking? > >>> > >>> Thanks again - I appreciate your time, > >>> Derek > >>> > >>> On Jul 20, 2007, at 5:26 PM, David P. Reed wrote: > >>> > >>> > >>>> You are not bottlenecked by Squeak, but instead are idle. And the > >>>> reason is quite simple, I suspect. Croquet is not designed to > >>>> flicker your screen at 250 fps or whatever just so you can say "my > >>>> graphics card is fast". It actually limits the framerate, so that > >>>> other computational tasks you might run are allowed to run, and if > >>>> those are quiet, the framerate is NOT increased. > >>>> > >>>> Some video gamers focus on framerate as their model of systems > >>>> performance. That really seems irrelevant to Croquet. But if you > >>>> want a higher framerate, just find the scheduling of the redraw task, > >>>> and set it to run at a high framerate. You may not be able to do > >>>> anything else, but you'll have your eyecandy and bragging rights. > >>>> > >>>> > >>>> Derek Arndt wrote: > >>>> > >>>>> Thanks John, > >>>>> > >>>>> I'm coming back to this specific issue as I would like to have a > >>>>> better understanding of where the framerate is going. With many > >>>>> optimized objects in the scene I am unable to obtain an acceptable > >>>>> framerate and I can't help but feel I'm being limited by the rate of > >>>>> which key methods are being fired in squeak. > >>>>> > >>>>> I've adjusted the configuration in the plist without any noticeable > >>>>> results. Below is a link to the shark profile - I'm not used to > >>>>> reading much outside of the application's symbols (and because this > >>>>> code isn't a C the results aren't very useful for the app itself). > >>>>> I'm interested to see what you can gleam from the profile if > anything: > >>>>> > >>>>> http://img409.imageshack.us/my.php?image=picture1hj4.png > >>>>> > >>>>> Interestingly enabling higherPerformance doesn't change the low > >>>>> framerate when rendering many objects on screen (which I would take > >>>>> to mean the bottleneck is in rendering the objects - but the > >>>>> framerates are much less then I would expect) > >>>>> > >>>>> Thanks for your time John, > >>>>> Derek > >>>>> > >>>>> On Jul 20, 2007, at 10:46 AM, Peter Moore wrote: > >>>>> > >>>>> > >>>>>>> *From: *John M McIntosh <[hidden email] > >>>>>>> <mailto:[hidden email]>> > >>>>>>> *Date: *June 12, 2007 3:21:01 AM CDT > >>>>>>> *To: *[hidden email] <mailto:[hidden email]>, Derek > >>>>>>> Arndt <[hidden email] <mailto:[hidden email]>> > >>>>>>> *Subject: **Re: [croquet-dev] Rendering Performance* > >>>>>>> *Reply-To: *[hidden email] <mailto:[hidden email]>, > >>>>>>> John M McIntosh <[hidden email] > >>>>>>> <mailto:[hidden email]>> > >>>>>>> > >>>>>>> Derek I've never looked at the Open/GL croquet drawing with > >>>>>>> relationship to the squeak displayscreen drawing. If you are using > >>>>>>> the carbon macintosh vm, there are some info.plist parms see > >>>>>>> http://www.smalltalkconsulting.com/html/squeakinfoplist.html say > >>>>>>> SqueakUIFlushPrimaryDeferNMilliseconds which affect drawing > >>>>>>> performance for the non open/gl stuff. > >>>>>>> > >>>>>>> Use of Apple's Shark should tell you where the time is going, and > >>>>>>> how much clock time is used sitting in the VM is sleeping > primitive. > >>>>>>> > >>>>>>> On Jun 8, 2007, at 1:11 PM, Derek Arndt wrote: > >>>>>>> > >>>>>>> > >>>>>>>> Hey everyone - this is my first time posting to the list. > >>>>>>>> I've been a Mac shareware game developer for a number of years at > >>>>>>>> http://www.batteryacid.org and now I'm jumping straight into > >>>>>>>> croquet. > >>>>>>>> > >>>>>>>> One of the first things to strike me that I haven't been able to > >>>>>>>> improve is the low framerate. In the simplest of demos I'm > >>>>>>>> experiencing a maximum of 42FPS on a MacBook Pro (CPU not pegged, > >>>>>>>> almost zero vertices or fragments on the screen). I've spent > >>>>>>>> some time using the popular debugging tools and experimenting by > >>>>>>>> rendering nothing in TSpace -> RenderSpace:port:depth:ghostFrame: > >>>>>>>> and reducing the large number of GL state changes submitted to > >>>>>>>> the driver. > >>>>>>>> > >>>>>>>> Sure it's easy to find obvious places of graphical improvement, > >>>>>>>> but getting little improvement and not finding a clear graphical > >>>>>>>> bottleneck leads me to think there is other limiting in place (or > >>>>>>>> timers that specify how often to render). Is this correct? > >>>>>>>> > >>>>>>>> Thanks for your time, > >>>>>>>> Derek Arndt > >>>>>>>> > >>>>>>>> PS. Does croquet have VBL syncing? > >>>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> > >> > ========================================================================== > >> = > >> > >>>>>>> John M. McIntosh <[hidden email] > >>>>>>> <mailto:[hidden email]>> > >>>>>>> Corporate Smalltalk Consulting Ltd. > >>>>>>> http://www.smalltalkconsulting.com > >>>>>>> > >>>>>>> > >> > ========================================================================== > >> = > >> > >>>>>>> > >>>>>>> > >>> > > > > |
«
Return to Croquet - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |