Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: M20090912-0800 OS: OS X 10.6.0 and 10.6.2 Eclipse Build IDs: 3.4.0 I20080617-2000 and 3.5.1 Carbon M20090912-0800 JVM: 1.6.0_15-b03-219 http://bugs.adobe.com/jira/browse/FB-23023 Reproducible: Always Steps to Reproduce: 1. Setup a laptop with Snow Leopard and an external monitor 2. Open Eclipse on the external monitor 3. Open a JFace SourceViewer-based editor with a file that has enough line numbers (~100) e.g. Open a .java file with enough content to scroll 4. Vertically scroll 5. Observe that the line numbers did not update as the scroll position changed 6. Move the Eclipse window to the main monitor 7. If your editor is still scrolled, the line number will update as soon as the window move is finished
Links to others with the same experience: http://steve-brown.id.au/it-stuff/programming/eclipse-line-numbers-not-scrolling-on-osx.html http://support.aptana.com/asap/browse/STU-4254 http://forums.adobe.com/message/2271332 Is there a workaround and if so will it work using carbon?
Fixed up the platform/version info so it ends up in the right bucket.
I've been experiencing this problem on my Flex Builder plug-in using Eclipse 3.4 on Snow Leopard. The only curiosity that I've recently found is that sometimes I can get the lines to cooperate if I put my browser (FF) onto the same monitor and get FP10 to run. It is not consistent, but occasionally makes a difference and works. Monitor: Samsun SyncMaster 204B MacBooK: 2.16 GHz intel Core 2 Duo OS: 10.6.1 (haven't seen a real reason to go to 10.6.2 yet) Eclipse: 3.4.2
I could not reproduce this on Leopard (10.5.8). Don't have access to a dual monitor machine running Snow Leopard yet.
I reproduce this all the time with Snow Leopard. Please make this a high priority. A lot of developers use multiple monitors.
Always reproducible with the following setup: - MacBook Pro running Snow Leopard (10.6.2) - Additional 24" monitor that becomes the main monitor when plugged in (i.e. it displays the dock) - Eclipse 3.5 macosx-carbon build 20090621-0832 (shown in the "about" dialog) When changing the monitor setup, i.e. plug/uplug the additional monitor: - line numbers stop scrolling, - additional markers (errors, breakpoints) aren't displayed. The solution is to restart Eclipse everytime the screen setup changes. This is *very* annoying!
Lakshmi, Can you reproduce this?
I've reproduced this multiple times. I've clarified my steps to reproduce from my original comment: Steps to Reproduce: 1. Setup a laptop with Snow Leopard and an external monitor 2. Open Eclipse on the primary monitor (make sure this is the secondary monitor, e.g. no menu bar) 3. Move Eclipse to the secondary monitor 4. Open a JFace SourceViewer-based editor with a file that has enough line numbers (~100) e.g. Open a .java file with enough content to scroll 5. Vertically scroll 7. Observe that the line numbers did not update as the scroll position changed 8. Move the Eclipse window to the main monitor 9. If your editor is still scrolled, the line numbers will update as soon as the window move is finished Other notes (posted from Adobe Flash Builder bug http://bugs.adobe.com/jira/browse/FB-23023) * Snow Leopard only * Multiple monitors only * Happens in all FB editors and also Eclipse editors (Java, Text, ANT) * Line numbers on the secondary monitor will always fail to scroll * The same behavior happens even when the window spans both monitors and the majority of the window is on the secondary monitor * When in this state, resizing the window will update the line numbers until you start scrolling again * One workaround is to set the secondary monitor (normally the external monitor) as the primary monitor and reboot. In Display Preferences, drag the menu bar graphic to the desired monitor.
(In reply to comment #8) > 1. Setup a laptop with Snow Leopard and an external monitor Jason - We don't have this hardware. We have iMacs with single monitors only.
(In reply to comment #9) > (In reply to comment #8) > > 1. Setup a laptop with Snow Leopard and an external monitor > Jason - We don't have this hardware. We have iMacs with single monitors only. Even if you have an iMac, grab another monitor, use the mini-DVI port, and see if you can reproduce it on a secondary monitor. I don't think it is a laptop only problem, it is secondary monitor problem w/ Eclipse and Mac 10.6
We don't have a mini-DVI adapter either. We have requested one.
(In reply to comment #7) > Lakshmi, Can you reproduce this? I have the secondary monitor setup, but no Snow Leopard yet to test this.
After the call to arms on twitter, I took a stab at testing on this bug. I tested the following (all carbon) releases downloaded today: 3.5.1 3.5.2RC3 I20100209-2300 I could reproduce the issue on both 3.5-based releases, but I couldn't reproduce it on the 3.6-stream release at all. I haven't actually attempted to debug the problem (and frankly, I'm not sure where to begin, as I've done no Carbon programming) but someone more knowledgeable about Carbon could check the differences between 3.5.2RC3 and I20100209-2300 to see if anything jumps out at them.
Forgot to mention runtime specifics: OS: Mac OS X 10.6.2 Java: java version "1.6.0_17"
Thanks Anthony for the testing. I believe the changes for bug#275686 fixed this problem in 3.6.
I can (In reply to comment #15) > Thanks Anthony for the testing. > > I believe the changes for bug#275686 fixed this problem in 3.6. I've confirmed this. I redid my test on 3.5.2RC3 to make sure that I could reproduce the issue again, then checked out the origin/R3_5_maintenance git branch and cherry-picked the following commit: commit b0c3f77a0bdc623fd48c73ba20767ddf3eacf70f Author: mkeller <mkeller> Date: Thu Oct 8 19:22:34 2009 +0000 Bug 275686: [painting] Rulers should not draw outside of SWT.Paint After exporting that build of jface.text into my cocoa workbench, I could no longer reproduce the error.
(In reply to comment #16) > I can (In reply to comment #15) > > Thanks Anthony for the testing. > > > > I believe the changes for bug#275686 fixed this problem in 3.6. > > I've confirmed this. I redid my test on 3.5.2RC3 to make sure that I could > reproduce the issue again, then checked out the origin/R3_5_maintenance git > branch and cherry-picked the following commit: > > commit b0c3f77a0bdc623fd48c73ba20767ddf3eacf70f > Author: mkeller <mkeller> > Date: Thu Oct 8 19:22:34 2009 +0000 > > Bug 275686: [painting] Rulers should not draw outside of SWT.Paint > > After exporting that build of jface.text into my cocoa workbench, I could no > longer reproduce the error. Will this work on 3.4? 3.5 and 3.6 don't support AS3 and Flex 3 dev. Are there easy steps for users to test out the jface fix from 3.6 to 3.4?
> Will this work on 3.4? It should, but someone would have to backport the patch to the R3_4_maintenance branch. Should not be too complicated since that code didn't change much and I don't see problematic dependencies. > 3.5 and 3.6 don't support AS3 and Flex 3 dev. It's probably more the other way 'round (they don't support 3.5 and 3.6). I guess the user portion of this bug can be considered fixed by bug 275686, but "new GC(..)" probably still has problems on the second monitor.
There may still be a bug in GC, but since this case is fixed in 3.6 already, I'm decreasing severity to 'normal'
(In reply to comment #18) > > Will this work on 3.4? > It should, but someone would have to backport the patch to the R3_4_maintenance > branch. Should not be too complicated since that code didn't change much and I > don't see problematic dependencies. There's a patch for anyone developing Flex in 3.4. Here's a blog w/ a patched file and steps to fix: http://www.quilix.com/node/75
(In reply to comment #20) > There's a patch for anyone developing Flex in 3.4. Here's a blog w/ a patched > file and steps to fix: > > http://www.quilix.com/node/75 The "wrong rulers on the secondary monitor" bug only appears in the carbon-port of eclipse, which is (at this time) still much, much more efficient (!!!) than the cocoa-port in the matter of screen display, particualary regarding text-editor scrolling. Therefore, cocoa-eclipse is definitely *unusable* (for me) by now. The "fix" provided at the link above eliminates the "wrong rulers", yes, but furthermore gives us the sluggish scrolling of the cocoa-port! argh... This (IMHO critical) carbon-eclipse bug is quite long-outstanding now - with no real fix in-sight, which is rather unacceptable for me, as a commercial software-developer with (unfortunally) no SWT development experience (otherwise I'd like to support you with pleasure, of course). So, the one-and-only-workaround is to make my seconadary monitor the primary one with dock and menu bar (waste of space on a monitor originally fully designated for eclipse, only). "One more thing" (but I don't know if I'm right or wrong): Perhaps, the carbon's "rulers bug" doesn't appear if the two monitors are identical and therefore could be driven with the same vertical refresh rate and vblank timings. My monitors are not the same, but I determined that under MacOSX the secondary monitor shows no tearing with horizontally moving windows (which is not quite natural!) but with a lower "visual" refresh-rate compared to the primary monitor. This little magic in MacOSX may be the key to fix the bug... Anyway, good luck!
No, I was wrong. :-( It seems to be neither a matter of primary or secondary monitor, nor of left or right monitor. I tried all alternative configurations - the bug always appears on the 16:9 screen only, never on the 4:3 screen. My setup: OS: Mac OS X 10.6.3 Java: java version "1.6.0_17" Left monitor: 4:3 TFT, DVI cable, rotated by 90 degree (correct rulers) Right monitor: 16:9 TFT, VGA cable (rulers not updated, bug present)
==I HAVE A SUBPAR WORKAROUND MY SETUP: MacBookPro 17" with Snow Leopard and external 22" Cinemascreen. The external screen gets this eclipse "line number" bug when used. The main MacBook screen does not get this bug at all. ==WORKAROUND AS FOLLOWS This is not ideal but if you resize eclipse window taking up eiher BOTH SCREENS or a smaller window size with the middle of the eclipse window between monitors (half on the external and half on the main screen) the line numbers work. This of course looks funky but at least you don't have to dedicate the entire screen from both monitors.
Created attachment 166057 [details] Patch for org.eclipse.jface.text I supply a patch that make the rulers update properly with no noticealbe drawbacks. Indeed, this isn't a true bugfix, because just the doubleBufferPaint() methods of the ruler classes are modified, so that they allocate a fresh Image object on every paint. The bug itself is propably located in the carbon-swt JNI library, as GC.drawImage() seems not to work reliable if the given Image is not just created. If you don't want to build the plugin with the patch applied by yourself, you may try my version compiled for eclipse-3.5.2: http://rapidshare.com/files/380276694/org.eclipse.jface.text_3.5.2.r352_v20091118-0800_patched.zip Just replace the existing org.eclipse.jface.text_3.5.2.r352_v20091118-0800.jar in your eclipse/plugin folder with the one contained in the ZIP.
That patch might be good as an emergency fix but I think checking it in and closing this bug would be a mistake. Better to understand and then fix the underlying SWT problem that's occurring. Given that re-allocating the Image fixes it, I wonder if the problem is something along the lines of the Image's native resource getting bound to a particular screen, and refusing to paint elsewhere. I.e., whichever screen it's painted on first?
(In reply to comment #25) > That patch might be good as an emergency fix but I think checking it in and > closing this bug would be a mistake. Yes, we won't release this. But thanks to Patric for pinpointing the problem.
(In reply to comment #24) > Just replace the existing org.eclipse.jface.text_3.5.2.r352_v20091118-0800.jar > in your eclipse/plugin folder with the one contained in the ZIP. Thank you very much for sharing this file. > That patch might be good as an emergency fix but I think checking it in and > closing this bug would be a mistake. It's not that it "might be good", it IS good. I would like to bring this to the attention of all: today, I restarted Eclipse 3.5.2 several times because of this problem: - I used File > Restart - I quit Eclipse so that the running app marker disappeared from the dock below the Eclipse icon. - I closed my user session. - Out of despair, I restarted my laptop. All of this to no avail. - Even worse, when I brought the window back to the laptop screen, the line numbers did not scroll with the text. Which brought me to Google, whose first answer was this bug report where I read all comments. Clearly, the "just restart Eclipse" or even "just reboot" thing does not always work. So I had to say thanks to Patrick Sauer. I really can't return to the Cocoa version, with its horrible text scrolling that reminds me of the Amstrad CPC when I was writing BASIC programs. Anyway, thanks guys for Eclipse. Really. Just restarted coding in C++ with Visual Studio and... nothing beats Eclipse as to my user experience.
(In reply to comment #27) > So I had to say thanks to Patrick Sauer. I really can't return to the Cocoa > version, with its horrible text scrolling that reminds me of the Amstrad CPC > when I was writing BASIC programs. If that's all that's keeping you from Cocoa, check out a 3.6 build. All of the scrolling performance issues have been fixed.
I have just upgraded MyEclipse to v 9.0 which has org.eclipse.jface_3.6.1.M20100825-0800.jar and I STILL have this scrolling issue on large resolution 2nd monitor (1920 x 1080) This is based on Eclipse 3.6 so from following the comments below expected this to work. This is very very frustrating, and if making my large 2nd monitor a waste of money, as I cannot use It !!!!!! I am on Mac OS X 10.6.5 From some quick testing. * If resolution is same on both monitors, issue still occurs * If you move window fully into macbook screen, no issue, scrolling line numbers work. * If you move window, with most of screen on macbook screen, no issue. * If you move window, with most of screen on 2nd monitor, issue occurs again. Please Please Please can we know when we will get a fix, or I will have to find another IDE. Many thanks Mark
(In reply to comment #29) You don't need to switch IDEs for that especially when there is a workaround. See my comment #27 and the hack offered by Patric in comment #24. I don't have a Mac system anymore but I think you can apply the patch yourself to the source code... which is the beauty in open source. The benefits are worth it. If that can be of any comfort, think of line wrapping... which doesn't work and won't before long (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=35779).
(In reply to comment #30) Thanks Amenel Voglozin for the reply, I agree I don't want to move away from eclipse. As I said in my previous comments, I cannot find the package for org.eclipse.jface.text I have MyEclipse 9.0 M1 which packages Eclipse 3.6.0 If you can tell me a) Where I can patch this version I would be happy to try. Many thanks Mark
Hi Mark, I'm not familiar with jface so I'll let others comment on where to find the appropriate packages/classes/methods. However, I'd say off the top of my head that you need to download the sources for JFace from the usual Eclipse downloads page... maybe they are included with the sources of SWT but I'm not sure one way or the other. Sorry I can't help more.
This problem is happening because Quartz is caching an image representation of the double buffered image used by the ruler and the cache does not get cleared when the image data changes (GC drawing). CGImageRef is supposed to be immutable, so this is valid behaviour. Somehow the cache is not cleared only in 10.6 for the secondary monitor. The problem does not happen in 10.5. I have found no API in Quartz to force the cache to be cleared without recreating the CGImageRef. I will attach a patch workaround that recreates the CGImageRef when drawing is performed in the SWT image. This fixes the problem with no performance degradation, but it can be potentially harmful because the handle of the SWT image changes. This will change the image hashCode as well, so if the image is stored in a hash table, it will not be found anymore.
Created attachment 185793 [details] patch that recreates the image
Note that the patch above only applies against HEAD (3.7). Here is a simple snippet that reproduces the problem. import org.eclipse.swt.widgets.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.*; public class PR294929 { public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(display); // shell.setLocation(-1000, 100); final Image image = new Image(display, 300, 300); final Color[] colors = new Color[]{ display.getSystemColor(SWT.COLOR_RED), display.getSystemColor(SWT.COLOR_GREEN), display.getSystemColor(SWT.COLOR_BLUE), display.getSystemColor(SWT.COLOR_CYAN), display.getSystemColor(SWT.COLOR_MAGENTA), }; shell.addListener(SWT.Paint, new Listener() { int i; public void handleEvent(Event event) { GC gc = new GC(image); gc.setBackground(colors[i++ % colors.length]); gc.fillRectangle(image.getBounds()); gc.dispose(); ImageData data = image.getImageData(); System.out.println("pixel=" + data.palette.getRGB(data.getPixel(0, 0))); long time = System.currentTimeMillis(); for (int j = 0; j < 1; j++) { event.gc.drawImage(image, 0, 0); } System.out.println("time=" + (System.currentTimeMillis() - time)); } }); shell.addListener(SWT.MouseDown, new Listener() { public void handleEvent(Event event) { shell.redraw(); } }); shell.setSize(300, 300); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } image.dispose(); display.dispose(); } }
(In reply to comment #35) Thanks Silenio for the excellent response. Last night I did a clean, uninstall, remove all directories etc, then did a fresh install, and Hey Presto... line numbers are now scrolling on my 2nd monitor And at different resolution (1920 x 1080) to my macbook pro screen. Regards Mark
Carbon is not a supported platform anymore.
