Re: Optimization ideas (was Re: 64 bit version of Quesa)

[James W. W. <os...@jw...>]

On Feb 27, 2007, at 3:23 AM, Roger Holmes wrote:

> On 27 Feb, 2007, at 03:08, James Walker wrote:
>
>> I was looking at the view state stack, and wondered if we really need
>> the attributeSet member of TQ3ViewStackItem.  It causes a
>> Q3Object_Duplicate call every time we push the stack, and it looks
>> like
>> it's only there to support Q3View_GetAttributeState and
>> Q3View_GetAttributeSetState.  Internally, we only call
>> Q3View_GetAttributeSetState when writing view hints, and never call
>> Q3View_GetAttributeState.  So I would think that whenever
>> Q3View_GetAttributeState or Q3View_GetAttributeSetState is called, we
>> could just build an attribute set on the fly from the various
>> attribute
>> members of TQ3ViewStackItem.  Anyone see a problem with that?
>
>
> I am not sure how much generality we would lose by doing this. I did
> come across a program which included custom attributes in its data  
> which I
> picked up on in the Microspot Renderer. I do use lots of custom
> attributes but our ones do not affect the rendering. I would rather  
> use custom
> groups or custom geometries to do those sorts of things.
>
> I think we can check if there any other attributes which we don't
> understand.  If there are some then we proceed as now, otherwise we  
> do as you
> suggest.  Hopefully the former case will be very rare. Maybe we  
> could have a
> flag to ay if there are currently any custom attributes there, and  
> only do
> the full check when the attribute set gets changed.
>
> I agree we do not want to be calling Q3Object_Duplicate for every  
> group
> in the data.

I'm not sure how any custom attributes would get in that attribute  
set.  It looks like the only way an attribute is added to that set is  
by e3view_stack_update_attribute, which is called by  
e3view_stack_update only for specific known attribute types.