|
|
Crashes While Using GL Tools Patches I've been having quite a few 'hard' crashes (the kind that require force-rebooting of the machine) while using Quartz Composer with GL Tools patches lately. I think the GL Line Structure patch might be the one to blame, as I've had a couple of these crashes on connecting the structure input to an instance of this patch. I can't seem to find anything in the System or Console logs about it, but if it happens again, I'll have a look straightaway. Sorry to be the bearer of bad news... a|x 2Gb RAM X1600 256mb Latest Quartz Crystal MacOS 10.5.6 QuickTime 7.6 |
Have you tried running the Quartz Composer application in an Empty Project with debugging via Instruments?
I recently discovered this and am amazed at how useful it has been proving to be. It doesn't tell one absolutely everything and the Console logs might well be having a hard time noting down a crash of some sorts.
However, you could also be stuck in a cache loop :-(
Clear Quartz Composer's cache. [~/Library/Caches/QCCompositionRepository-com.apple.QuartzComposer.editor.cache]
Then try making a new Line Structure item.
The problem potential , if still there, will manifest and if run within the Empty Project Debug routine will probably help to show what is wrong at break points.
gl line structure... isn't doing anything particularly "dangerous" -- read from a QC structure, pump out GL stuff in immediate mode.
perhaps immediate mode has been getting progressively less stable as time goes on -- I've had panics and oddities when just using stock patches on mutliple displays. shrugs
also, see if it happens on 10.5.7 -- lots of gpu driver updates there, from what I've heard (mostly of the nvidia persuasion, but perhaps some ati love as well?).
Ah, thanks for that. I haven't used a QTZ in an application, so never thought to try this. I'll give it a go though.
Cheers,
a|x
Would it be quicker to use a VBO, rather than immediate mode?
Just downloading 10.5.7 now. Let's see if it helps.
a|x
in immediate mode, we can just pump out the vertices as we read them. if we used vbo we'd have to scan the structure to see how much we're going to use, allocate a block big enough, then re-read it for data. passing the data multiple times tends to yield no performance benefit.
if we stored it for subsequent frames, and the structure didn't change, it'd be a win. But most people don't seem to use line structure without making the structure dynamic...
(for a similar comparison, check out the vbo renderer in particle tools vs. the "standard" renderer -- the standard renderer even includes 2 context switches because VEE sucks, and it's still faster or at least a tie with the vbo renderer in every test case we've thrown at it. -- and that's traversing C structure, which is much cheaper than traversing QCStructures.)
I see :)
a|x