Whoah.. It's getting really complicated with all the references floating 
around..

Tom Cooksey wrote:
>>> This will actually
>>> decrement the ref count on the real palette (making it 2, one for src &
>>> dest surfaces).
>>>       
>> That is usually the result but the real  story is a bit more complicated.
>> The interface object itself is reference counted. The reference count is
>> 1 when you create the object. Calling Release() on it will decrement that
>> reference count (AddRef() can be used to increase the ref count). When
>> the ref count reaches 0 the interface object's destructor is called which
>> will drop the reference on the real palette (CorePalette).
>>     
>
> So _both_ the interface object and real object are ref counted? Why?
>
>   
Exactly!
Because an interface is an object, too.
You can also have an interface without pointing to something (without an 
implementation).
An example why this makes sense is this:
you make something, like a palette. you create an interface to it. so 
the palette has refcount 1, and the interface has refcount 1. You can 
now _bound_ the palette to a surface. the palette refcount is now 2. If 
you now release the interface, the interface refcount will drop to 0, 
causing automatical deletion of the interface, which in turn will 
release the palette refcount. but this is still 1, so will not be 
deleted; in fact, it will be deleted as a consequence of 
deleting/releasing/whatever the surface that it is connected to.
>> But normally you don't really have to think about this stuff. Just
>> follow the simple rule of calling Release() on all interface objects
>> you created when you no longer need them.
>>     
>
> But I didn't create an interface class, IDirectFBSurface created the instance 
> of the interface class inside GetPalette()?
>
>   
Correct.
Whenever you Get an Interface, you _Get_ it. a copy, of course. so you 
need to give it back using Release() :)
>   
>>>>> If I understand what you're saying it does, but SetPalette will then
>>>>> take ownership of it, calling delete when it's destroyed. But I still
>>>>> have to call Release on the newly created object to decrement it's
>>>>> ref count. Otherwise, when the new surface is destroyed it won't
>>>>> delete the palette because it's ref count > 1?
>>>>>           
>>>> SetPalette will not touch the interface reference count.
>>>> So no taking ownership there.
>>>>         
>>> But this sounds to me that I'm also going to end up with the interface
>>> object never being deleted. Surely if the dest surface doesn't take
>>> ownership of the interface object in SetPalette, I'm responsible for
>>> freeing it? So I need to call release and then delete?
>>>       
>> There is no delete. Just Release().
>>     
>
> Ok... so who deletes the interface object? Presumably the dest surface, which 
> takes ownership of the interface object in SetPalette()? Or rather the dest 
> surface will increment the interface's ref count and decrement it again when 
> the surface is released. If, when it's decremented, the ref count is zero, 
> the 
> object will be deleted. Correct?
>
>   
dest surface cannot take ownership of palette interfaces!
if you do SetPalette, the only thing you give is the palette. or rather, 
you add a reference to the palette object..
So interface refcount goes thus. GetInterface -> 1. Release() -> 0. -> 
interface destroyed.

> I guess all I really need to know is that I have to call Release() and I 
> don't 
> have to delete it. It just seemed very strange, especially after reading that 
> there's a new IDirectFBPalette::CreateCopy() method in the 1.3 API. Oh well, 
> thanks for the help.
>
>   
CreateCopy has a simple reason... If you do GetPalette and SetPalette, 
there is still only 1 palette... So if you change it in 1 location, it 
also changes in the other! So if you want to have 2 palettes that are 
almost the same, you would do GetPalette, CreateCopy, SetPalette, so you 
have really 2 'physical' separate palettes.

hth
Niels
>
> Cheers,
>
> Tom
>
>
>
>   


-- 

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------" 

_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users

Reply via email to