{Spam?} Re: Gem sucking whole CPU for no visible reason... intermitently WAS Re: [GEM-dev] Re: [PD-dev] oprofile - streamlining Pd/gem patch

[james tittle]

hey all,

...sorry I've been silent lately:  recovering from a bad sore throat/ 
cold!  This has definitely been the year of being sick for me, so far...

On May 17, 2006, at 1:06 PM, B. Bogart wrote:
> in some cases it does seem possible to remove the separators, in  
> others I
> suppose I would have to use matrixpop and matrixpush... anyone have an
> example patch of this?

...first off, you'd need to know what matrix you're wanting to push/ 
pop, fr'example:
                 [GLdefine]<-[GL_MODELVIEW<
                 |
[GEMglPushMatrix]

...then all you'd need to do is to [GEMglPushMatrix] before something  
that would change that matrix, and [GEMglPopMatrix] afterward... 
[separator] basically does this for three matrices at the same time,  
at the beginning of it's Gem::render():  GL_COLOR, GL_TEXTURE, &  
GL_MODELVIEW...these are then popped back in the postrender() call...

> so I removed many of the separators from my patch and we'll see if  
> that
> improves things.
>
> The patch seemed to be running fine before I put in [rubber], the
> abstraction that contains the rubber stuff is [single-moment]. But now
> that I think about it its probably just because the drop of frame- 
> rate is
> only visible with rubber in it, maybe it was always doing this, but I
> don't recall so... I did upgrade gnome, but it seems very unlikely  
> that
> would cause these troubles.

...I think this could be due to the immediate mode drawing in  
[rubber]:  I'm currently trying to switch it over to vertex_arrays/ 
vertex_buffer_objects, but it's not exactly straightforward (need to  
rewrite how the "masses" are stored)...

jamie