Bad Shark trace? What does OGLProfiler say?
62k triangles is a fair amount. I would expect the memcpy() from the cache to the GemState to eat the most time.
On 8/9/06, james tittle tigital@mac.com wrote:
hey,
...I've got a model that's fairly large and seems to be causing our model-loading display system some problems: almost immediately pd/ gem start to eat up 100%cpu...this also happens when using [vertex_model]:
vertex_model: model->numtriangles 62692 vertex_model: model->numgroups 2 vertex_model: model->numvertices 143258 vertex_model: model->numnormals 143860 vertex_model: model->numtexcoords 143258 vertex_model: i 0 vertex_model: src2 94038 vertex_model: src4 188076
...anyway, according to shark, 98% of the cpu time is now being spent recursively in GemBase::continueRender(), and I'm not really sure why this would be, or what that function's actual duty is? Most of the time I'm seeing about 4 levels of the following:
GemBase::continueRender GemBase::gem_renderMess GemBase::gem_MessCallback pd_typedmess outlet_anything
...is continueRender called when an object isn't finished doing it's thing? Or does anyone have other ideas about what's going on?
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev