Re: [xmlvm-users] Releasing of CGBitmapContextRef / CGImageRef

[JR S. <sc...@we...>]

I believe that CFRelease is still needed in CFType.finalize() for 
reasons OTHER than UIGraphics. For example, CGBitmapContext.create() 
generates a CGBitmapConextRef.  Currently there is no corresponding 
".release()" method defined in the Java interface for CGBitmapContext 
(e.g. no way to call CGContextRelease).  A similar issue exists with 
CGColorSpaceRelease. It seems the logic here was that context would be 
released in the finalize method derived from CFType.  But if this is 
commented out, the context is never released -- and there is no 
mechanism to do so.

Assuming I understand your previous post, it would thus seem to me that 
EITHER,
1)  A release method needs to be defined for CGBitmapContext (and other 
similar methods), or
2)  The call to CFRelease in CFType.finalize() needs to be restored, 
which may entail some changes in UIGraphics

The new iOS interface is not an option for me, as it current does not 
appear to implement CGBitmapContext and several other objects.

One fairly simple workaround is to define a Java class with a static 
CFRelease(...) method and implement this in C.  This seems to work for 
me, but its a bit of a hack for something that seems fairly crucial / 
fundamental.

JR

On 7/17/2012 1:25 PM, Paul Poley wrote:
> I believe the reason I commented out the "CFRelease" in 
> CFType.finalize() is that it was only there in the first place because 
> of a bug in UIGraphics.  Namely, popContext() was popping the context 
> & then releasing the current context, which is wrong & a different 
> context altogether.  It should've been releasing the context that was 
> popped, so I fixed that.
>
> Then, the bug in CFType.finalize() which called CFRelease could be 
> fixed.  I.e. if it was left in there, it'd be incorrectly released 
> twice.  Note that CGContextRelease is equivalent to CFRelease.
>
> Thanks,
> Paul
>

-- 
J.R. Schmidt
WebMO, LLC