The Data Loader only scans the folder when the input path changes. It creates the output structure, then starts a background thread that progressively loads the images found within the folder hierarchy, updating the output structure as and when necessary. That thread stops when complete.
The QTZ does frequently change the input path, but only once every minute or so, and I'm fairly certain there are no leaks in the plugin - although I may well be wrong.
If anyone's curious (or fancies stealing some source code), here's the Xcode project to the DataLoader plugin.
http://upload.clayinteractive.co.uk/data/20110720150948-37388-DataLoader-20110720(1.2).zip
Thanks!
A.
On 20 Jul 2011, at 14:38, George Toledo wrote:
> Are you constantly scanning with your Data Loader plugin, or have you built in an option to disable scanning once you've retrieved your data? I'd look at that in regards to the memory issue.
>
>
>
>
> On Wed, Jul 20, 2011 at 8:03 AM, Adrian Ward <email@hidden> wrote:
>
> Hey vade
>
> Thanks for the thoughts - most appreciated.
>
> No image ports to/from the actual QTZ, just lots of images coming from custom plugins, and going through JavaScript patches before being spat out in other structures for rendering. The biggest potential culprit is a Data Loader plugin that scans a folder hierarchically and returns a massive NSDictionary filled with strings, images and structures of strings and images (etc). I'm fairly certain there's no leaks in that plugin (having watched Object Allocations carefully) but I'm convinced there's a leak somewhere internal to QC, or OpenGL, or the NVIDIA/ATI drivers as a result of what it's doing. Maybe 30% of the time I have crashes, I've also seen lots of malloc error 12s in the log, so I know I'm pushing capacity (yes, the app is 32 bit).
>
> With NSZombies, the problem happens much quicker but it's still the same. Very often the last thing the app spits out before SIGBUS'ing is "Could not allocate register file: 12", which I'm finding it hard to know what this means, other than it's another malloc error 12 (out of memory).
>
> Another potential culprit is a different plugin (StyledTextPlugin, one that you've helped me with before) that uses WebKit to render a HTML string. It uses an NSAttributedString which is created from a chunk of HTML using WebKit, but this has to be done on a separate thread to avoid corrupting QC's rendering pipeline. Because WebKit doesn't seem to be thread-safe, on some crashes the backtrace is convoluted to say the least - and I'm not convinced this isn't causing the problem either.
>
> Oh, I've also seen QC crash in the same way - so it's nothing to do with my app specifically.
>
> Currently my not-so-ideal solution is to allow the app to crash quietly and focus on relaunching it as quickly and seamlessly as possible - not ideal.
>
> Is it worth me sharing an Instruments trace, or is that mostly a useless gesture?
>
> Thanks and all the best
>
>
> Ade.
>
>
>
> On 18 Jul 2011, at 18:22, vade wrote:
>
> > Are you feeding images into published input image ports, or pulling images out of published image ports, or is everything handled internally a single QTZ?
> >
> > Try enabling NSZombies and see if you can re-create the crash or leak of objects. Does this happen consistently at the same point in your code, on app launch for example, or is it totally inconsistent? Is your app 32 bit? are you hitting a memory limit? Have you checked for leaks at all?
> >
> > Does yoru 3rd party plugin handle image processing?
> >
> > The thread overhead is afaik "well known" for quicktime, especially AIC and modern codecs that can use multiple decode threads. I often see tons of threads in apps like VDMX, because of pre-rolling, etc, and I dont think they get cleaned up quickly either.
> >
> >
> >
> > On Jul 18, 2011, at 12:05 PM, Adrian Ward wrote:
> >
> >>
> >> Hi all,
> >>
> >> I'm starting to see an increase in sporadic crashes of an app we've written that uses a QCView that has loaded a large and complex QTZ. This set up has been running for quite a long time and the only significant change is the content that the QTZ loads. We've been through the content repeatedly to see if we can find a culprit but there is nothing immediately obvious.
> >>
> >> Now, I know better than to expect anyone here to give me a solution, but I thought if I posted a crash report someone might be able to suggest an area I should be looking at. The below report tells me Thread 0 has crashed whilst QCImageManager was optimising its caches, and I'm guessing it's likely that a resource somewhere got over-released. So I know I need to be careful about memory allocation. I'm fairly certain I have been in the custom plugins that are loaded. I'm also aware that the app is loading LOTS of content - object allocations during the load phase peak at about 600MB so maybe I'm just being greedy?
> >>
> >> The 32 QCDatagramReceiver threads are not a surprise - I have 32 Network Receiver patches somewhere deep in the QTZ.
> >>
> >> However, whats with the ~68 threads that are in QuickTimeH264.scalar and AppleIntermediateCodec?! I don't have that many Movie Importers running at the same time! I might have some sitting idle that sometimes get used to load video, but not all at the same the time. Generally I'd only ever have a maximum of two Movie Importers loading a video at the same time, and the rest of the time the others would have their Movie Location set to blank so they wouldn't have loaded any video. I know we use both H264 and AIC for video content so this is a point of concern.
> >>
> >> So, does this suggest that QC isn't freeing resources (or killing old threads...) used by Movie Importer? And is it plausible that this could be pushing my app to a EXC_BAD_ACCESS?
> >>
> >> Sorry I can't post a QTZ demonstrating this in action, nor reduce the project to reproduce the issue reliably.
> >>
> >> All suggestions welcome! Unless they involve phone hacking, please.
> >>
> >> Thanks,
> >>
> >>
> >> Ade.
> >>
> >>
> >>
> >>
> >>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
