Community
Participate
Working Groups
I was on Linux Mint 18 and just upgraded to Linux Mint 19, during which process Eclipse Neon (which I had installed off the system disk) when run prompted me to update to Eclipse Photon. This I did. But it crippled my work. I can no longer use Eclipse. To illustrate the problem I took a desktop recording: https://www.youtube.com/watch?v=CL6U-miipcA In it I illustrate the problem. I am just moving the mouse around and clicking here and there or not clicking. In particular moving the mouse off the editor and then back onto it seems to often cause a slow refresh, editor goes blank and repaints slowly. Of note are the many tests I have done to confirm: 1) This is independent of the editor. That is I can use the PyDev editor or the built in editor or another one from the right-click drop down menu on a file in the project explorer and they all do the same thing. 2) I blew away my workspace, eclipse, ~/.eclipse and downloaded a completely clean Eclipse Photon, then cloned my github repo anew and tried again. Same problem. Alas still present. 3) So I created a new account on my PC, logged in with that, and repeated, complete fresh download of Eclipse Photon, and got clone of my repo and tried that. Problem is not there. That's encouraging. Worth observing is that this is a problem introduced I suspect by Eclipse Photon, though maybe by Mint 19, not easy to differentiate right now, but I will continue testing shortly to try and narrow that down (I can run Mint 18 and Photon and see, I can maybe also download Neon on Mint 19 and check - yet to see if I can do these things. It seems unlikely to be a Mint 19 issue because of 3) above, and more likely a Photon issue. But because of 3) above I am tempted to conclude there are some hidden configs in the home directory of my account that are not in the newly created account that interact poorly with Photon. Alas I can on see ~/.eclipse as a candidate and it's not (on account of 2 above), but there a load of legacy . files and directories in my very mature home folder, and it may be that some X related configs are involved. I have not finished testing clearly, it's very time consuming, frustrating and a road block to development for now. I wanted to file now however to check if: a) This rings any bells regarding known issues b) I can receive any pointed guidance on tests that can help nail a cause including possibly inxi or eclipse config dumps etc attached here that might provide clues (though its fairly vanilla Mint 19 with vanilla Eclipse Photon exhibit the problem. Perhaps someone better versed in the kind of events that trigger such a slow editor repaint (slow perhaps as it may be doing a file reload?) can advise and request further details from me? (I have of course given it a severity of "blocker" as it is blocking my productivity. You may of course revise that downwards as I expect "blocker" refers much rather to a release blocker - though if this were at all a widespread experience - not extremely rare and down to some odd platform issue specific to me - then it would probably be a release blocker too).
If I understood correctly, you also see it in the text editor - correct? Can you please try with http://download.eclipse.org/eclipse/downloads/drops4/R-4.8-201806110500/
Yes indeed, the standard text editor in Eclipse is doing it. I've been very pressed for time, but have a plan for testing to do. I have downloaded clean images of Photon, Oxygen, Neon and I have a clean workspace, and two text files in it. I just open one, and see if the reload is happening, if it's mild I open the second to have two open. Both are identical files just a READM.md file in fact from a project. I just quickly tried the drop you linked to and it exhibits the problem. Alas. The main clue I have to explore is profile pollution and X. My recollection is, that the clean profile I have runs Photon fine without this issue. To wit, what I have to do to diagnose a contributing cause will be a load of profile comparing and testing. Essentially, tests will look like: Create two new profiles TestGuy1 and TestGuy2. Copy my existing home directory to TestGuy2. Try running eclipse photon logged in as TestGuy1 and then as TestGuy2. Expected result from tests so far (i.e. I'll be doing this to confirm this null hypthesis) is that TestGuy1 is good and TestGuy2 has this problem. If that's not confirmed, have to reappraise test plan. If that's confirmed, then I copy all the .* folders from TestGuy2 to TestGuy1 and see if TestGuy1 has the problem. If yes, I delete half of them and retest, and so on by method of bisection I converge on the config folder that causes it. This all relies on the hypothesis holding that it is caused by something in the home folder. Anyhow, as you can see, I have a job ahead and I've been seriously snowed under with a pile of projects, children and sleep deprivation ;-). But it's on my list as I rely on Eclipse for so many projects that are on hold for now (c'est la vie, I'm overcommitted as is clearly - most of these projects are mine alone, desire projects not anything I'm beholden to anyone for, which is why they can sit in a holding pattern I guess).
This is frustrating me immensely alas. I have in the interim tried the following: 1) Created a new account and tested. All is good. The problem is absent. 2) Checked eclipse on my standard account and the problem is there. Impossible to use. Eclipse. I am using the Same photon binaries in each case, and a completely fresh workspace with a fresh project with two text files in it. All free of pollution. I removed the ~/.eclipse and ~/.p2 directories and the ~/.liclipse diretory for good measure. Problem still exists. Emptied my trash. Emptied ~/.cache. Problem persists. So onto my new account. Tried to replicate the problem. Copied all my .x* and .X* files/folders to the new account, logged out and in and tried. Problem not there. Copied all my .* files and folders to the new account, logged out and in again. Problem not there. So the new account is good. The old account has the problem. But it's not in the workspace, it's not in any .* config files or directories that the cause lies. That is what frustrates me. I don't know what else may differentiate accounts. The name is different. Can it be that dconf or gsettings differ that are not stored in $HOME/.* files/directories? More to research. The pragmatist in me is tempted to run with the new account ... but the idealist wishes to understand the cause and have it recorded here. It must be findable, if I can somehow bring the new account to be identical to the old in every respect ...? The question being where on Linux migth account specific configs reside outside of $HOME. Research.
Finally I have got around to the tedious task of nailing this. Took me weeks. Most of which was paring down my own home dir after a decades worth of collecting lint, to the point where I could copy it in real time and not wait 10 minutes (yep, I had some collected lint alright, basically a decade of neglected sorting and archiving jobs of photos, documents and more, so I used this as a catalyst to catch up on that and it took ages). Once done ... I could use the method of bisection to move between my home dir which has the problem and a fresh account which does not and step by step, I nailed it down to ... wait for it: .xinputrc This one file, in my home dir, if I remove it, relieves the problem and Eclipse Photon runs fine again! What a relief. So, now on to diagnosis for the Eclipse team for of posterity in case anyone sees this again. $ cat .xinputrc # im-config(8) generated on Sun, 25 Oct 2015 10:23:51 +1100 run_im xim # im-config signiture: 1b2043d99db448584fe13d49bee8a78d - $ cat /usr/share/im-config/data/*_xim.rc # vim: set sts=4 expandtab: if [ "$IM_CONFIG_PHASE" = 1 ]; then XMODIFIERS=@im=none GTK_IM_MODULE=xim QT4_IM_MODULE=xim CLUTTER_IM_MODULE=xim fi I admit I have no idea what all that does, nor how I got it. Though clearly it's related to vim somehow. But that one line in .xinputrc, namely "run_im xim" causes the Eclipse Photon editor to become functionally unusable with endless screen slow editor screen refreshing as you move between panels in the IDE. I would genuinely appreciated it if someone on the Eclipse development team saw this and lent comment, so that as a community we are closer to understanding. Alas I would have research every one of the lines in xim.rc, and only new to look there because of the documentation here: http://manpages.ubuntu.com/manpages/trusty/man8/im-config.8.html I will leave this bug open until acknowledged by the dev team because really it is not resolved, I have simply found the culprit and a way to work around the problem, but the problem exists, is not understood or documented here, and that should be a goal - namely to understand it and lend comment as to whether a fix to Eclipse would see this never arise again or if it's something that is an understandable and unavoidable consequence of one or more lines in that xim.rc script ...
I may confirm this issue. I'm facing exactly similar symptoms on Linux Mint after some system updates. And it is related to input method. Must be after some update the input method was changed but user configuration in home folder (.xinput.rc) was not updated. Running im-config utility and choosing default input method solves this issue. So problem in system not in Eclipse.
Thanks for confirming. I have been happily using Eclipse again since I found it and fixed my .xinputrc. The one thing I'm not sure I agree with is that it's not an Eclipse issue. There certainly seems to be an Eclipse issue at play, as I don't believe any IDE or software should become unusable likes this because of what's in .xinputc like Eclipse seems to if it contains what mine contained. Least of all when the contents seem fine to every other piece of software. I am still wondering why the behaviour of Eclipse responds as it does to these .xinputrc settings. Understanding this would be most pleasing. But alas I do not.
(In reply to Bernd Wechner from comment #6) > Thanks for confirming. I have been happily using Eclipse again since I found > it and fixed my .xinputrc. The one thing I'm not sure I agree with is that > it's not an Eclipse issue. There certainly seems to be an Eclipse issue at > play, as I don't believe any IDE or software should become unusable likes > this because of what's in .xinputc like Eclipse seems to if it contains what > mine contained. Least of all when the contents seem fine to every other > piece of software. > > I am still wondering why the behaviour of Eclipse responds as it does to > these .xinputrc settings. Understanding this would be most pleasing. But > alas I do not. Ok. As an Eclipse user I agree with you that changes in system components those are breaking some application functionality should be tracked more easily. Particularly with this issue it is not obvious for user to determine a cause of the problem. And this is a big problem of the Eclipse. And it is not first such issue. Eclipse uses GTK on Linux platform for UI as I understand. GTK it self is not very good peace of code. And API breakage is a usual thing for this project. But, Eclipse has to provide more informative errors and diagnostic in case when it's operation differs from expected. Other side is a behaviour of the text editor in described conditions. Here is most probably a bug. Rendering thread is blocked by input reader thread. So we re experiencing lags in refreshing.
The xim input method is known to cause problems. See bug 517671. Newer Eclipses warn about this, and still newer Eclipses enforce ibus on Gnome. *** This bug has been marked as a duplicate of bug 517671 ***
Thanks you Thomas for the clarification! A very useful contribution here. But: 1) I will note that the sheer number of duplicates of this issue is quite stunning and indicative of the importance of solving this permanently. 2) You suggest it has been fixed (solved) in "Newer Eclipses", which is great. I presume you mean newer than Photon! So I checked and admit I find the numbering suddenly confusing as Photon seems the last named release and the project moved to quarterly unnamed release. Which fine of course, and I'm downloading the latest 2019-09. But I wonder if you notice this and would be so kind as stating clearly that this warning is now in place in Eclipse 4.9 onwards, or whatever version really. Just that I like explicit clarity in areas like this as I am about embark on a gamble - installing the latest (a gamble because my move from Neon to Photon cost me much grief reported here! but one I readily undertake as keeping up to date is recommended on the whole).
