Re: [platform-swt-dev] Image caching on Mac OS X Mountain Lion

[Stephan Aßmus <superstippi@xxxxxx>]

Hi,

Am 03.12.2012 um 19:50 schrieb Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>:
> I have fixed a bug on this area a couple of weeks ago. Take a look at: 
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=339132 
> 
> More specifically on commet#42 
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=339132#c42 
> 
> The way I got the cache to be flushed was by calling NSBitmapImageRep.bitmapData() when the GC drawing on the image is destroy.  Hopefully this will work for you as well. 

thanks a lot for the pointers. This didn't fix my problem, but I have obtained more information. :-)

First of all, my method of obtaining an NSBitmapImageRep object don't reliably result into obtaining such an object. For an image which has been painted once, it retrieves an NSCGImageSnapshotRep instead on the third invocation. Which in turn doesn't have the bitmapData() selector.

Second, my original mail left out an important bit of information: I also create an SWT GC for the Image, and generate the image contents via both my native lib and the SWT GC. On Mountain Lion, creating a GC appears to make a difference in what representations end up existing for the NSImage.

When I *don't* create a GC for the Image, I can avoid the caching problem by re-attaching to the bitmap buffer each time I draw. I have to replicate the package private Image.getRepresentation() method which always returns an NSBitmapImageRep. Then it can be observed that the bitmap buffer memory location alternates between each call:

Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 416764160
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 416764160
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 442659072
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 416764160
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 442659072
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 416764160
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 442659072
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 416764160
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 442659072
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 416764160
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 442659072
Attaching: rep: org.eclipse.swt.internal.cocoa.NSBitmapImageRep{1371648}, data: 416764160
…

The first two lines may be the same because between those lines, the image has not been rendered to the screen. I mean the first line is my original attach-call, then the next lines are the new attach-calls before the image is rendered to the screen.

However, when I also create a GC for the Image, then the NSBitmapImageRep instance may or may not be different between each render cycle, and it may or may not return the same bitmap buffer, different NSBitmapImageRep instances my return the same memory location, and the same NSBitmapImageRep instance may even return a different memory location...

I will have to test this on my other Mac which has Lion. But presumably the changes to NSImage were done in Lion, so doing testing on Snow Leopard or Leopard may be more important.

I also tried wrapping all my rendering inside NSImage.lockFocus() and unlockFocus(), but that just gives me a black image.

Best regards,
-Stephan