Hello List / George,
It doesn't seem to get smoother on my side. This is wicked! Jason, did
you figure out how to make it work?
I am trying to figure out a solution where the interpolator would not
be replicated inside the iterator with each image,
maybe using the <Range> patch and <Rolled over value> which could
produce a circular system.
I'm busy on another project so I'll try this in a few days…
dimitri
On 24 févr. 09, at 04:20, George Toledo wrote:
I don't know about you guys, but unchecking synchronous download on
the image downloader makes this perform much better on my system,
removes the stutter on the 7th image, and levels out the frame rate
dips, and makes the images not do that weird stutter step on loading
8 out of 10 times ( and I mean "loading" from a freshly started qtz,
with the synchronous unchecked). When I do see the stutter on load,
it is very minor. GMAX3100 here...
-George Toledo
On Mon, Feb 23, 2009 at 9:57 PM, Jason Belec <[email protected]>
wrote:
Well this version is much better. I did realize that in Quartz Prefs
you can set the Maximum FPS, I had my set at 30 FPS previously so I
set to Unlimited. Now we run between 30 and 60 and things constantly
jump back and forth with minor variations.
I do notice the dreaded stutter now and again. Various in frequency
and intensity depending on speed.
I get the same CPU usage, I've got something similar in a large
project, I will pull it out tomorrow and see if I can compare and
offer you far better advice.
Every 7th image loaded is the stutter/hesitation.
--
Jason Belec
1-613-482-9737
[email protected]
On 23-Feb-09, at 8:02 PM, Dimitri Delcourt wrote:
Hi List, Chris, Troy, Jason,
I'm not a professional developper, but i would say from the
experiment that the problem lies in the interpolator inside the
iterator. Would that be correct?
Here's what i did:
- Downsampled the pictures, now they weigh 1/4 of what they weighed
before
- Slowed down the animation
- Changed to backgrounds "Nature" because there are more images
- Added an "Enable images" option (Christopher's remark)
- Added a "Force loading to VRAM" option. Tricking QC by displaying
all images at once and for a few seconds in a separate iterator
- Added a "View range" option to kill processes some sprites
processing at will (to release the iterator pressure, Jason's remark)
- Added a "Speed boost" option that interpolate 60 times a second
(to test Troy's sync remark)
Observations:
- Downsampling the images doesn't seem to help. Activity monitor
displays 8-12% of CPU and it doesn't accelerate calculations.
- Displaying all images at once eventually helps at the beginning,
if you don't, each image is obviously read from disk the first
time, and it stutters heavily at each new image until they have all
been displayed once.
- Killing sprite processes helps a bit, but the animation still has
some stalls even with only 3 iterations
- Boosting the speed reveals that the interpolation is not synced.
It should more or less display the same images in the same position
which it does to some extent, but you will see that after a while
it gets desynced. (Famous bicycle wheel and camera effect)
So even with a few, scaled down images in the iterator, the
interpolation does simply not sync to the screen refresh rate. Even
when disabling the images! I see the fps dancing around 59, 42, 33,
19, up again. What does actually hit the CPU?
Interesting information: on my side, I am alternatively loading a
folder with 1400 photos (600px * 600px) and the performance is not
worse, not better (aside from the fact that it needs 30 seconds to
force load them in VRAM).
I'm attaching the updated composition, still hoping that someone
will find an obvious logic flaw that i can't see myself...
dimitri
<Directory_Interpolation_test02.qtz>
On 23 févr. 09, at 23:16, Troy Koelling wrote:
Be aware that QC framerate is synced with the monitor refresh
rate. That means that if it can't keep up at the monitor's refresh
of 60fps it's going to drop to the next multiple of two: 30fps. Or
if the composition is running pretty good at 30 then something
hits the CPU and it has to drop 5 frames so it can actually handle
25fps, it will draw at 15fps because of the refresh sync.
There are ways to make it draw as fast as possible without the
sync in your own application, but the Quartz Composer app doesn't
support* that. It would likely cause tearing in the rendering
where only half the frame was updated before put on screen.
If you want to read more about this, google for
NSOpenGLCPSwapInterval
On 23 févr. 09, at 19:07, Jason Belec wrote:
I ran this under latest Leopard on MacBookPro 17" CoreDuo 2GB RAM
and had 29.0-29.9 FPS consistently varying between these values -
BUT, every now and then, without anything else being done I would
see a drop to about 15 FPS then right back up. I also noticed a
small stutter between images that can be exasperated easily by
increasing the size, specifically the width quite a bit. I think a
buffer is needed or pre-load and attach images as a single image
(or a few) and roll it as they scroll across the screen.
--
Jason Belec
On 23-Feb-09, at 12:47 PM, Dimitri Delcourt wrote:
Christopher,
could it be that one of your magic plugins is secretly handling
the rendering?
on my MBP the fps is lounging between 58 and 15, and funnily
enough i have serious jitters.
I wouldn't mind if it stayed around 30 fps or even 20 fps if it
stayed constant —
But even if i cap the rendering to 20 fps in the preferences, I'm
experiencing different rendering speeds over time (even in the
course of a second), the GPU seems to stall, become more fluid,
stall again.
I'll test further according to your tips and report, I really
need to get this going on 3 screens pretty soon!
Thanks for the time!
dimitri
On 23 févr. 09, at 15:52, Christopher Wright wrote:
- I am having this problem with my MBP 2.53GHz, NVidia 9600M
GT, and on my iMac 2.4GHz, ATI Radeon HD 2400 XT.
Looks like you're hitting a case of the "NVidia's Drivers are
sucktacularly bad, or QC has some magical code that only
misfunctions on nvidia hardware" issue (this pops up from time
to time, Apple is aware of the issue, the only workaround is
get a different video card [not possible got MBPs]). I'm
getting ~250 fps on my GMA950, so it's definitely not a
difficult composition. A rare case of Old soundly beating New :)
Just kidding -- tested it on my MBP (nvidia also), and it's
still puling 280-440 fps. I guess you mean the slight stall
only (drops to ~55-65fps for me), as reported by the minimum fps
mode reporter.
Those images should be vram. OpenGL Profile on an nvidia says
that 97% of the gl time is spend in CGLFlushDrawable, while for
other compositions I have it's much smaller (a few percent at
worst). Not sure if that's significant, but it looks like it's
capping the maximum framerate pretty severely.
Removing the image structure input, it doesn't really affect the
performance (the minimum frame rate jumps a bit, but is still
suffering), so it's not a texture problem. Removing more inputs
doesn't really help either (so it's not a complex-graph-
evaluation thing)
Ultimately: create a new composition, add a clear patch, add an
iterator, add a sprite to the iterator, add a patch time to the
enable input of the iterator (so we get it running, instead of a
static composition), and then an fps, and you'll peak at about
90-100 fps (no image loading/texture swizzling/whatever). On my
machine, that's only a few fps higher than textured for me, so
perhaps iterators are the culprit?
--
[ christopher wright ]
[email protected]
http://kineme.net/
.......
.......
Dimitri Delcourt
Graphiste indépendant
C/o C-Side
Rue de la Coulouvrenière 8
CH - 1204 Genève
T + 41 78 843 76 04
[email protected]
.......
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
