Hello Dimitri, I did check back through several things, and we never
really got the issue fully resolved. We did figure out certain speeds
that worked ok. This happens with text scrolling across the screen as
well. We did eventually change how we presented things that sort of
rolled up onto the screen with the intent of returning to it. I
haven't really had time to see how much of this I can resolve with the
current tool set but I am playing with it inbetween things. The stuff
I oversaw was all for use on the AppleTV and that framework.
It has caught my attention again and I will see what I can resolve for
you. I did notice that adding a small gap (at least a pixel) between
images helped alot of flickering on various edge issues. We also used
BASH to build an array that was loaded a certain intervals. This
allowed us external changes to the data in the array (images). And the
composition only had to worry about display. It solved several things,
but that may not work for you.
As I said, I'm going to play around with it some more. Have you talked
with those talented people over at Kineme? I've always been impressed
with some of the solutions.
Back to you asap.
--
Jason Belec
1-613-482-9737
[email protected]
On 26-Feb-09, at 6:57 PM, Dimitri Delcourt wrote:
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/jasonbelec%40rogers.com
This email sent to [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]
