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