[GEM-dev] continueRender weirdness?

chris clepper cgclepper at gmail.com
Thu Aug 10 17:13:12 CEST 2006


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 at 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 at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060810/da347f6a/attachment.htm>


More information about the GEM-dev mailing list