Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #338575 +++ This is on Mac Cocoa using GEF 3.7 and Eclipse 3.7. Something screwy is going on with the thumbnail view. Make a Logic Example and open up the Overview and show the thumbnail in that view ("Show overview" button). Initially the thumbnail is blank (which is wrong), then if you create and/or move objects in the Logic Editor the thumbnail is out of sync. (It's OK on Windows 7 and Mac Carbon so it's a Cocoa thing). --------------------------------------- I've cloned the original bug to track it from SWT side. The changes for the Bug 329569 seemed to have caused this. Will investigate this further.
Hi Alexander & Philip, I'm able to reproduce this problem with the Thumbnail example as suggested in the bug. I tried to extract a SWT only snippet from the example, but I'm unable reproduce the problem with my snippet. Could you please create a SWT snippet so that it is easier to debug the problem? Thanks.
(In reply to comment #1) > Hi Alexander & Philip, > I'm able to reproduce this problem with the Thumbnail example as suggested in > the bug. I tried to extract a SWT only snippet from the example, but I'm unable > reproduce the problem with my snippet. Could you please create a SWT snippet so > that it is easier to debug the problem? Thanks. Hi Lakshmi, what do you mean by "SWT only"? Thumbnail is part of Draw2d. Do you mean without a Thumbnail?
(In reply to comment #2) > (In reply to comment #1) > > Hi Alexander & Philip, > > I'm able to reproduce this problem with the Thumbnail example as suggested in > > the bug. I tried to extract a SWT only snippet from the example, but I'm unable > > reproduce the problem with my snippet. Could you please create a SWT snippet so > > that it is easier to debug the problem? Thanks. > > Hi Lakshmi, > > what do you mean by "SWT only"? Thumbnail is part of Draw2d. Do you mean > without a Thumbnail? I meant a snippet that doesn't use Draw2d, and uses only SWT APIs. Is it easy to make one?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Hi Alexander & Philip, > > > I'm able to reproduce this problem with the Thumbnail example as suggested in > > > the bug. I tried to extract a SWT only snippet from the example, but I'm unable > > > reproduce the problem with my snippet. Could you please create a SWT snippet so > > > that it is easier to debug the problem? Thanks. > > > > Hi Lakshmi, > > > > what do you mean by "SWT only"? Thumbnail is part of Draw2d. Do you mean > > without a Thumbnail? > > I meant a snippet that doesn't use Draw2d, and uses only SWT APIs. Is it easy > to make one? For me, this is impossible because I can only see the bug manifesting in the Thumbnail. Sorry.
(In reply to comment #1) > Hi Alexander & Philip, > I'm able to reproduce this problem with the Thumbnail example as suggested in > the bug. I tried to extract a SWT only snippet from the example, but I'm unable > reproduce the problem with my snippet. Could you please create a SWT snippet so > that it is easier to debug the problem? Thanks. Well, I was not yet able to do so either. It does not seem to be a "straightforward bug". What I investigated so far is that it does not seem to be a question of missing paint events, because they seem to correspond in 3.7M3 and 3.7M4 (this was my first assumption) w.r.t. the thumbnail example. If you have set up a local workspace with the SWT sources, I think the easiest way to track this down would be to simply check the respective SWT revisions between M3 and M4 with the thumbnail example (to identify the commit that introduced the regression).
(In reply to comment #5) As mentioned in the bug description, this bug is caused by the changes made for Bug 329569. The change was to use NSCalibratedRGBColorSpace in-place of NSDeviceRGBColorSpace. Changing the color space back in Image.java seems to fix this. But I was trying to get a testcase to understand/debug why/how this is failing for the Thumnail example.
(In reply to comment #6) > (In reply to comment #5) > > As mentioned in the bug description, this bug is caused by the changes made for > Bug 329569. The change was to use NSCalibratedRGBColorSpace in-place of > NSDeviceRGBColorSpace. Changing the color space back in Image.java seems to fix > this. But I was trying to get a testcase to understand/debug why/how this is > failing for the Thumnail example. Unfortunately, I am unable to produce such a testcase. Is it still possible that this bug might be fixed?
Increasing severity to major, because this is a regression that from GEF's point of view is quite nasty. I will try to help with identifying an SWT-only test case to reproduce the problem. Nevertheless, the underlying SWT problem is already identified. So even if we do not succeed in doing so, it would be nice we can see this fixed in 3.7.
(In reply to comment #6) > (In reply to comment #5) > > As mentioned in the bug description, this bug is caused by the changes made for > Bug 329569. The change was to use NSCalibratedRGBColorSpace in-place of > NSDeviceRGBColorSpace. Changing the color space back in Image.java seems to fix > this. But I was trying to get a testcase to understand/debug why/how this is > failing for the Thumnail example. Would it be unreasonable to ask to roll back the changes from the fix to Bug 329569? Looking at the 5th comment there it seems that it created other problems, too.
Created attachment 191998 [details] patch This patch changes the colorspace used in GC & Image back to DeviceRGB. This fixes the problem for the Thumbnail Example. The original changes (for Bug 325153) also include changing the colorspace for many Controls. Silenio, is it also required to change the colorspace for the controls?
Adding Scott for comments.
The original problem that motivated the change to NSCalibratedColorSpace was a bug in the color chooser dialog. Colors were coming in with device color but were being improperly converted to calibrated color. Further review revealed we were using a mix of device and calibrated color, so I made changes to make sure we were consistent in the use of calibrated color, which is what you should always be using. Device color is reserved for things like printing or color matching. The problem then, however, was that NSImage and NSBitmapImageRep had bugs on 10.5 that broke the JUnit tests for SWT. Those were fixed for 10.6, so I had to do some triage to make sure the unit tests worked on both platforms. Is this bug showing up on 10.5 only? I'll try on 10.6 and report back. I _believe_ this has to do with creating a new Image from ImageData.
To fix this specific problem you only need to change line 848 in Image.java: rep = rep.initWithBitmapDataPlanes(0, width, height, 8, 3, false, false, OS.NSDeviceRGBColorSpace, OS.NSAlphaFirstBitmapFormat | OS.NSAlphaNonpremultipliedBitmapFormat, width * 4, 32); No other changes in GC or Image are needed. All of the JUnit tests pass on 10.6. I'm no longer able to run tests on 10.5, so if you want to test first to be sure, please do so. While this fixes the problem I'm not sure if it introduces any subtle color problems.
(In reply to comment #12) > > Is this bug showing up on 10.5 only? I'll try on 10.6 and report back. I > _believe_ this has to do with creating a new Image from ImageData. This is on Snow Leopard, 10.6.x.
Sigh!. I looked back at the history of these color space changes. It started with bug#325012. As turns out the code in HEAD does not fix that problem (calibrated color space coming in and out of the dialog). The initial fix Scott did was to use device color space both ways and that actually worked. But then we decided to use calibrated color space everywhere and broke bug#325012 again. Before bug#325012, ColorDialog was inconsistent: the value coming in used device color space and the value coming out was converted to calibrated color space. It took me some time, but I remember why that was done. If the device color space is used both ways and the user selects the "RED" color in the palette of the ColorDialog (third tab), the returned color was not 255,0,0. This happens because a color in calibrated color space is returned by the dialog and we convert it to device color space. This conversion is wrong. I really believe we need to be consistent and use the same color space everywhere. As it turns out calibrated color space causes to many problems even though it is the recommended color space in the documentation. https://bugs.eclipse.org/bugs/show_bug.cgi?id=325153#c0 I will attach a patch that changes everything back to device color space including those cases we were inconsistent before (ColorDialog, IME, etc). The patch also has a fix for the bad conversion.
Created attachment 192234 [details] fix I released this patch to HEAD. Lakshmi, please give it a try. I have not actually tested the GEF case, but it should work. Close when you are done. Thanks!
I tested the Thumbnail example with HEAD and it works fine.
I can confirm this working again on the latest nightly build. Many thanks for the effort that went into sorting this out!
Hi All, I am able to reproduce the issue with GEF 3.7.1 and SWT 3.7.1 using the Logic Example. Excatly the same behavior as described earlier shows up. The issue should probably be re-opened.
Reopening bug due to Holger' comment.
(In reply to comment #19) > Hi All, > > I am able to reproduce the issue with GEF 3.7.1 and SWT 3.7.1 using the Logic > Example. Excatly the same behavior as described earlier shows up. > > The issue should probably be re-opened. It's still working OK for me. I'm using: Mac OS X Lion 10.7.2 Eclipse SDK Version: 3.7.1 Build id: M20110909-1335 Cocoa 64-bit GEF Version: 3.7.1.v20110830-1143-777D181B3Bz06C853E6964242 Build id: 201109112020 Can you list your setup detail?
Together with Alexander we found out that the issue was caused by the workspace setup. With a fresh new workspace the issue does not show up anymore. Somehow the old SWT version must have found its way into the runtime. Yet, we have no clue what is the root cause for this behavior. But that is a different issue we need to check and not related to this specific ticket.
Resolving as fixed due to Holger's last comment.
This has reappeared in OS X 10.8 Mountain Lion using Eclipse 3.8. Follow instructions in Comment #1.
I meant, follow the instructions in the original description. Can someone please re-open this bug as it's 100% reproducible on OS X 10.8 Mountain Lion and Eclipse 3.8 Cocoa 32-bit and 64-bit.
(In reply to comment #25) > I meant, follow the instructions in the original description. Can someone > please re-open this bug as it's 100% reproducible on OS X 10.8 Mountain Lion > and Eclipse 3.8 Cocoa 32-bit and 64-bit. Reopening...
Thanks for re-opening. Is this a result of the changes made for Bug 329569 re-appearing? Did something change in OS X 10.8 Mountain Lion to cause this? This is all working fine in OS X 10.7.
Is it a case of re-visiting the SWT Color spaces bug for Mountain Lion?
Perhaps this could be addressed for Mountain Lion?
We are working on getting a Mountain Lion. I will investigate once we have it.
(In reply to comment #30) > We are working on getting a Mountain Lion. I will investigate once we have > it. Thanks!
(In reply to comment #30) > We are working on getting a Mountain Lion. I will investigate once we have > it. I wonder if you managed to get a copy?
We have 10.8 now. I cannot reproduce bug#325012 on 10.8 and SWT has not made any changes in this area since we closed this bug the first time. So the only thing that seems to be broken is the GEF thumbnail example. Could someone add instructions how to run that sample? Where do I get the source, etc?
(In reply to comment #33) > We have 10.8 now. > > I cannot reproduce bug#325012 on 10.8 and SWT has not made any changes in > this area since we closed this bug the first time. > > So the only thing that seems to be broken is the GEF thumbnail example. > Could someone add instructions how to run that sample? Where do I get the > source, etc? The instructions are in Comment #1 and in the original Bug #338575
(In reply to comment #33) > We have 10.8 now. > > I cannot reproduce bug#325012 on 10.8 and SWT has not made any changes in > this area since we closed this bug the first time. > > So the only thing that seems to be broken is the GEF thumbnail example. > Could someone add instructions how to run that sample? Where do I get the > source, etc? Or can be seen on any GEF/GMG based RCP app or plugin using Eclipse 3.8.x and Mac Mountain Lion. Alexander, can you confirm?
(> Or can be seen on any GEF/GMG based RCP app or plugin using Eclipse 3.8.x > and Mac Mountain Lion. Alexander, can you confirm? I mean GEF/GMF.
(In reply to comment #34) > (In reply to comment #33) > The instructions are in Comment #1 and in the original Bug #338575 Sorry, I am not familiar with GEF. What do I need to load/install in eclipse to make a "Logic Example"?
I have upgraded my private Mac to Mountain Lion and can confirm the thumbnail view is broken (a change is not reflected there before performing the next one). You can simply install the GEF ALL SDK from one of our update sites (urls and zipped update sites are provided here: http://www.eclipse.org/gef/downloads.php), then in your workspace create some project and an example logic diagram via File->New->Example, choosing GEF(Graphical Editing Framework)-> Logic Diagram. In case you want to obtain the examples source code, you can alternatively use File->New-Example and then choose GEF (Graphical Editing Framework) Plug-ins->Logic to have the logic example plug-in source code added to your workspace. You can then create a runtime workspace and within it a logic diagram as outlined above. Alternatively (if you want to obtain the latest version also of Draw2d/GEF's source code), you can alternatively checkout the code from our Git repo as outlined here: http://wiki.eclipse.org/GEF/Contributor_Guide.
This hack in org.eclipse.draw2d.parts.Thumbnail.java (stop/start) works around the problem. I am still trying to understand what is the causing it. protected void paintFigure(Graphics graphics) { Image thumbnail = getThumbnailImage(); if (thumbnail == null) return; boolean running = updater.isRunning; if (running) updater.stop(); graphics.drawImage(thumbnail, getClientArea().getLocation()); if (running) updater.start(); }
SWT snippet that reproduces the problem. Somehow drawing the contents of the thumbnail in a asyncExec runnable causes this problem. import org.eclipse.swt.SWT; import org.eclipse.swt.widgets.*; import org.eclipse.swt.graphics.*; public class ThumbnailTest { public static void main(String[] args) { Display display = new Display(); final Shell shell = new Shell(display); final Image image = new Image(display, 200, 200); final GC gc = new GC(image); final Image image1 = display.getSystemImage(SWT.ICON_ERROR); display.asyncExec(new Runnable() { public void run() { Rectangle src = image1.getBounds(); gc.drawImage(image1, src.x, src.y, src.width, src.height, 10, 10, src.width / 2, src.height / 2); gc.dispose(); shell.redraw(); } }); shell.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { System.out.println("PAINT=" + event.getBounds()); event.gc.drawImage(image, 20, 20); } }); shell.addListener(SWT.MouseDown, new Listener() { public void handleEvent(Event event) { shell.redraw(); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
But wasn't the original root cause that as described in Comment #6? Is it possible that something changed in Mountain Lion that caused a regression?
I do not understand why the image colorspace change affected this problem in the past. This really looks like a bug in cocoa. The pixels of the image bitmap representation are not getting updated from the underlining CGImage. I looks like a caching problem. It could be that caching was not performed before 10.8 for images with the NSDeviceRGBColorSpace (just a guess). I found out that calling NSBitmapImageRep.bitmapData() when the GC is disposed is enough to flush the internal cocoa cache. This fixed the snippet above and the Logic example. Please try the latest. Fixed http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=38754f9669d64b603149eb0693559a15dd50c6b7
(In reply to comment #42) > I do not understand why the image colorspace change affected this problem in > the past. This really looks like a bug in cocoa. The pixels of the image > bitmap representation are not getting updated from the underlining CGImage. > I looks like a caching problem. It could be that caching was not performed > before 10.8 for images with the NSDeviceRGBColorSpace (just a guess). I > found out that calling NSBitmapImageRep.bitmapData() when the GC is disposed > is enough to flush the internal cocoa cache. This fixed the snippet above > and the Logic example. > > Please try the latest. > > Fixed > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=38754f9669d64b603149eb0693559a15dd50c6b7 Many thanks for the fix, I greatly appreciate it. I tested against the Eclipse 4.3.0 Nightly build N20121121-2000. However, my RCP app uses Eclipse 3.8.x and I didn't see the patch in that stream. Will it make it to the 3.8.x builds?
We need to get more testing in 4.3 before we can back port it. Reopening and setting the target milestone so that we do not forget.
.
(In reply to comment #44) > We need to get more testing in 4.3 before we can back port it. Reopening and > setting the target milestone so that we do not forget. Would be great if it could make it to 3.8.2. In the meantime I've hacked the org.eclipse.draw2d.parts.Thumbnail class's stop() method: // package private "drawable" field of GC is Image class Object image = MacOSReflect.getPrivateField(thumbnailGC, "drawable"); if(image != null) { // Call package private method getRepresentation() on Image to return NSBitmapImageRep type Object nsBitmapImageRep = MacOSReflect.executeMethod(image, "getRepresentation"); if(nsBitmapImageRep != null) { // Call NSBitmapImageRep.bitmapData() method as per fix in bug #339132 MacOSReflect.executeMethod(nsBitmapImageRep, "bitmapData"); } } The MacOSReflect class uses reflection to get Objects and methods in classes.
Patch backported to R4_2_maintenance and R3_8_maintenance
(In reply to comment #47) > Patch backported to R4_2_maintenance and R3_8_maintenance Thank-you!
I'm facing a similar problem. I opened a new bug (bug 564978), but I think leaving a comment here might be useful. If I do the following on a mac, the second file has the same contents as the first one. My code, simplified: Image myImg = new Image( Display.getDefault(), 100, 100 ); GC mygc = new GC( myImg ); // draw something // Saves the image to a file. saveImage( myImg ); // draw something else on the same image. // Saves the image to another file. saveImage( myImg ); myImg.dispose(); mygc.dispose(); If I do this after saving the first file, and before the extra drawing operations, the problem is solved: mygc.dispose(); mygc = new GC( myImg ); But I don't want to dispose and create a new GC, because of performance issues. On Windows it works perfectly.
