Re: TGeoElementTable::Instance (fwd)

From: Andrei Gheata <Andrei.Gheata_at_cern.ch>
Date: Mon, 25 Apr 2005 10:12:45 +0200


Hi Sue,

This is related to the current implementation of the paint mechanism and its interaction to TGeoManager. There is still some clean-up to be done for this to work. Currently the painter class is designed to be a singleton. Also, the 3D viewing mechanism accepts only one viewer at a time. It will still take some time to deal with this use case.

Cheers,
Andrei

Sue Kasahara wrote:

> Hi Andrei & Rene,
> Thanks! I've tested the fix and I seem to be able to build two
> geometries now in memory and switch between them. I'm wondering if
> you can expand a little bit on this restriction:
> > - do not try to draw in the same time 2 geometries
> I can see that it would be a problem to draw two geometries
> on the same canvas simultaneously, but I'm wondering if I should
> expect that it's possible to draw 2 geometries sequentially in the
> same root
> session after switching gGeoManager to point to the current geometry?
> In my own experiment this fails: the first geometry draws okay, the
> second does
> not.
> Thanks again,
> -Sue
>
> Andrei Gheata wrote:
>
>> Hi Sue,
>>
>> I will fix the problem with TGeoElementTable and let you know.
>> Hopefully you should not run into other problems - different
>> geometries can reside in the same time in memory - however you will
>> be the first testing this in detail. The only cautions you should
>> take are:
>> - set gGeoManager pointer to 0 before adding a new geometry in memory
>> (by whatever method)- if you have already one.
>> - switch gGeoManager to the active geometry before starting to use it.
>> - do not try to draw in the same time 2 geometries
>>
>> I will let you know,
>> Regards,
>> Andrei
>>
>>> Hi root team,
>>> I'm making use of the TGeo associated classes to build
>>> our detector geometries. We need to be able to build more
>>> than one geometry in the course of a job, and we store these multiple
>>> geometries in a loan pool of geometries available for use. These
>>> geometries are to be used within a vmc application, but also for other
>>> purposes.
>>> In order to manage multiple geometries in memory, I realize
>>> I need to manage the gGeoManager global pointer so
>>> that it points to the geometry in use and I've attempted to do this.
>>> I've run into my first problem however, in that I find that I receive
>>> a complaint when building a second geometry after the first is built
>>> which is:
>>>
>>> Error in <TGeoElementTable::ctor>: Element table already instantiated
>>>
>>> Investigating a bit, I see that TGeoElementTable is a singleton to
>>> hold the default list of elements, but it's not really treated like
>>> a singleton.
>>> For example, the TGeoManager destructor will delete the Instance.
>>> This is of course a problem when one has multiple geometry in memory,
>>> one of which may go out of use before another. Can this behavior be
>>> changed?
>>> A more general question: will I run into other problems trying to
>>> manage
>>> multiple geometries in memory in this way? How do you recommend
>>> handling
>>> this problem?
>>> Thanks,
>>> -Sue
>>>
>>>
>>>
>>
>
Received on Mon Apr 25 2005 - 10:13:11 MEST

This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:45:07 MET