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