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.
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