This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I'm trying to run Netbeans over the remote NX protocol (http://nomachine.com). Netbeans screen updates are very sluggish and error prone to the extent that it is unusable. I tried using -J-Dawt.nativeDoubleBuffering=false which removes the drawing errors, but it is still sluggish and of course it also makes it a very flickering expirience. The performance of the remote desktop itself is extremely good. Drawing on other programs runs very smoothly and fast, including other Swing applications! Amongst the tried Swing apps was Oracle's JDeveloper, which had no issues. It worked as well as any native GTK application. So the issue is actually very simple. What Swing tricks does Netbeans use, which properply speeds up things when run locally, but has a catastrophic result when run remotely over protocols like NoMachines NX protocol? And is it possible to turn of the tricks!
Reassigning to Core
We need more informations : jdk, build number, ... could you please provide more informations ? It would be also helpful to generate thread-dump of running IDE at time it's slow, could you also attach this output here ? Thanks in advance.
JDK: I've used 5.0(1.5.0_11-b03) and 6.0(1.6.0_01-ea-b01) Netbeans: Build 200610171010 It's an issue all the time and not specific to any window. To me it looks like all of the Netbeans window is drawn offscreen and then copied as bitmaped into the actual screen, which is a very bad strategi over remote desktops. Somehow it's related to double buffering strategies and perhaps also L&F. I think you need to try it out yourself. It's very simple though. The software from NoMachine http://www.nomachine.com/download.php is very easy to install and use! Just download the "NX Free Edition for Linux", "NX Node for Linux" and any one of the Clients (I tried both the Linux and Windows clients).
I don't know about any "Swing tricks" that netbeans does and can't find anything that would cause such performance degradation. Are you sure that other Swing applications behave differently? For example SwingSet2 demo in JDK demos? Lowwring to P4 as it's corner case...
BTW: antialiasing can probably make big difference in a remote display environment.
I use JEdit on a daily basis, having no problems (even when using subpixel antialiasing). I tried the mentioned SwingDemo2 - no problems. It's an all Netbeans issue. Even the newest combination of Netbeans 6.1 and java 6_u10 causes the sluggish window painting. Please, try it for your self.
I'm seeing this as well, using 6.7. It's very easy to reproduce this. I can assist with reproduction steps.
Try to remove UI parts and see if it still persists. I had similar experience on remote X with memory toolbar where gradient was used. You can hide toolbars and views and see if there is any specific component causing this.
The editor itself seems to be the culprit. At least, it still manifests when that's all that is visible.
Right, explorer trees seems to be OK but editor is basically unusable - all scroll operations are likely to corrupt the content of pane. I'll attach a screenshot. I do not see any other component to be visibly corrupted at the moment. I tried with NB6.{1,5,7RC1}. I use Sun's Java6 and openJDK java. NX version 3.3.0-6 Note that other Java apps works well - Swingset2, Notepad, I do not see any reports from IDEA users about problems like this (nor Eclipse though it is SWT). Also I tested to disable various optimization on NX side. Re Dafe's comment about this being corner case: think about all the people who have to run their tools remotely. For example because your company does not want you to keep copy of sources on your laptop. Nomachine's NX is a great solution for this - it gives you acceptable performance and latency when running X11 in a remote setup. I am not aware of alternative solution with comparable performance. Honestly this is S1-2 for me (think of it as a blocker for people if they want to switch to NetBeans).
Created attachment 83183 [details] a sample of corrupted screen content
Radime, thanks for the details. Reassigning to editor for now. Should be evaluated if the line rendering could be fixed.
I will try to ask Mila to look at it after we have 6.8 out of the door. Sorry guys, this is too late for 6.7 (there is still hope 6.7 patch though) ...
I meant to say "after we have 6.7 out of the door", I apologize for the confusion.
Strange we just use methods of Graphics and Graphics2D. I would like to rewrite the editor's rendering to TextLayout (either call directly SwingUtilities2.drawString() or copy that code) but originally I've planned to implement this in terms of issue 121357. Of course for 6.7 patching we would need a local fix so I'll try some local changes in DrawGraphics whether it helps or not.
Adding -J-Dsun.java2d.pmoffscreen=false fixes the problem for me (at least quick testing looks promising). The bad part is that the whole UI is slower with this so this is really a last resort. Thanks to http://brunovernay.wordpress.com/2007/12/11/remote-access-to-netbeans/ for the hint.
I've set up the NX server on Ubuntu 32-bit and client is Ubuntu 64-bit. I'm unable to reproduce the corrupted display in editor problem. Scrolling in both Editor and Navigator is relatively slow on JDK 1.6.0_13 (I can see two identical lines being painted) but there's no corruption in the displayed glyphs (finally the data are rendered correctly). On JDK 1.5.0_18 it scrolls considerably faster in both editor and navigator but still no corruption. Any clue what should I change to get the problem to appear?
Thanks Mila. My NX client is on Mac (notebook) and NX server runs on Linux (historically both 32- and 64-bit, a machine somewhere possibly under my desk).
I've now tested on Mac OS X 10.5.7 but unfortunately with similar results like on Linux i.e. no corruption and jdk 1.5 faster in scrolling than jdk 1.6. I'm wondering whether there could be any NB settings (e.g. current line highlighting etc.) that could affect the rendering? I'll try to play with it. I'll also try to switch to TextLayout rendering whether it would make any difference.
It happens to me when I scroll using the mouse and scrollbar as well as when moving cursor in editor with arrows (PgDw/PgUp is usualy OK). Turning line numbers on/off does not make any difference. My session settings is: Unix / Custom (no GNOME/KDE/...) / starts only terminal and uses floating windows.
Thanks, Radime, I was able to reproduce the problem. The key is to use Unix/Custom. I'm working on a fix.
I've tried TextLayout rendering but unfortunately there was no improvement.
Created attachment 83920 [details] TextLayout rendering diff
BTW I was able to reproduce the problem by dragging the scrolling button by mouse in tasklist as well (same with output window). And also with the navigator window although there it was a bit different in that once I had released the scrolling button then about one second later there was a sudden fresh repaint of the navigator component that fixed the problem. So I had to hold the scrollbar button by mouse and press Apple-Shift-3 to capture the whole screen into a file and crop it afterwards before attaching the picture to this issue. If we won't find any better fix for the editor repainting maybe we could use a similar workaround.
Created attachment 83922 [details] Broken tasklist
Created attachment 83926 [details] Broken navigator
A strange thing is that I can't get any such broken rendering with swing demo apps - SwingSet2 or Notepad. Anything special in our Window System? Stando, Dafe, don't you know what could be wrong?
Marek S. gave me a hint to try unchecking everything under Options->Miscellaneous->Appearance. Unfortunately this did not help either. BTW when dragging a scrollbar button I noticed painting artifacts inside the scrollbar itself too. These get eliminated by the delayed repaint (which I've described in an earlier note). Apparently just the navigator responds to that delayed repaint by refreshing itself but other components do nothing. If we could refresh editor upon that delayed repaint it should fix the problem (at least the one that I'm experiencing).
Created attachment 83931 [details] Scroll button painting residues
I'll commit at least the TextLayout painting diff although it does not fix the problem. http://hg.netbeans.org/jet-main/rev/ba04724b6ae0
Integrated into 'main-golden', will be available in build *200908130201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ba04724b6ae0 User: Miloslav Metelka <mmetelka@netbeans.org> Log: #95375 - NX remote: Very sluggish and error prone window painting. - TextLayout based rendering.
I wonder, has something been changed from 6.9.1 to 7.0.1 regarding this issue? I'm asking because since I use 7.0.1 in my environment (nxagent 3.4.0-16 running on Solaris 10 9/10 SPARC with the NX "thin client" being a Cygwin/X instance on Windows XP) these drawing errors, which I had before unless I specified -J-Dsun.java2d.pmoffscreen=false, seem to have disappeared. Whenever I start up 6.9.1 for comparison on that machine, I can always reproduce the drawing errors. With 7.0.1, I don't have them. In both cases using the same JDK 1.6.0_24-b07.
steg0: thanks for the report. I mark the issue as fixed.
Sorry to say this, but the problem still occurs in 7.0.1. I had to switch to NoMachine and Linux and the performance compared to local execution of Netbeans (Linux) is very, very poor. Lots of "tearing" in code editor, visible/slow rendering of file tree. :( Using: Netbeans 7.0.1 Java: 1.6.0_26 netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Xverify:none -J-Xmx1g -J-Dsun.java2d.pmoffscreen=false" (last option doesn't change anything) The remote machine is a very powerful one, so remote performance is (or should) not be an issue. On my slow local machine Netbeans works good, none of the issues can be found here. It seems still to be some issue with remote desktop handling. NoMachine client: nxclient-3.4.0-7.i386 Server: freenx-server-0.7.3-18.el6.i686 + nx-3.3.0-38.el6.i686 Any tweaks I could try?
The only additional knob I know of is the J2D_PIXMAPS environment variable. Theoretically this should/need not be set to "shared" for NX because shared pixmaps are very useless for NX anyway. So you *could* try one of the following: (1) export _NB_PROFILE_CMD="J2D_PIXMAPS=server" (2) patch nbexec to remove the J2D_PIXMAPS setting (if you have the privileges) (3) run nxagent with the -noshpix argument (if you have the privileges) (4) set the appropriate nxclient option I'm not too sure though, because the editor pane issue has gone away for me with 7.0.1 even with J2D_PIXMAPS=shared and all the other knobs left at the default values. But maybe it's worth a try.
Sorry guys, but it's not fixed. I've been using Netbeans on local machine for years, but every time I need to work over NX, I'm forced to use something else. It works fine over VNC, but not NX. I try every new NB version, but editor window performance remains to be very sluggish. Details regarding my latest attempt: Netbeans version: 7.1.2 JRE: "java version "1.7.0_05" Java(TM) SE Runtime Environment (build 1.7.0_05-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" Linux Distro: "Red Hat Enterprise Linux Server release 6.2 (Santiago)" NX: "NXAGENT - Version 3.3.0" Netbeans options: -J-Xms2048m -J-Xmx4096m -J-XX:PermSize=128m -J-XX:MaxPermSize=512m -J-Xverify:none -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J-Dsun.java2d.d3d=false -J-Dsun.java2d.ddoffscreen=false -J-Dsun.java2d.pmoffscreen=false Note that removing all these options and running Netbeans with default configuration doesn't show any noticeable change in text scrolling performance over NX - it affects indexing and NB performance in general, but not text scrolling.
(In reply to comment #36) > Sorry guys, but it's not fixed. > I've been using Netbeans on local machine for years, but every time I need to > work over NX, I'm forced to use something else. It works fine over VNC, but not > NX. > I try every new NB version, but editor window performance remains to be very > sluggish. If you don't have the drawing errors (comment 11, comment 25, comment 26), and it's "only" slow, then I think it's a different problem. Couldn't switching NX encoding e. g. to 4k-png (or others, depending on your link) help? I generally use 4k-png or 16m-rle with nxagent-3.5.0_5 over a reasonably quick WAN and it works just fine, definitely not slower than VNC. Note that disabling X11 shared pixmaps could still improve the situation because shared pixmaps can *reduce* performance over an NX link. See http://www.nomachine.com/documents/configuration/client-guide.php.
steg0 thanks for the comment. I have examined the view hierarchy's painting operations (whether there aren't any extra possibly larger repaints etc.) by using info at http://wiki.netbeans.org/EditorViewHierarchyLogging and it seems to be correct. When scrolling up/down there are mostly single-line repaints which corresponds to moving the data in buffer and just painting the rest. I have found one minor problem that end paragraph index of the lines being painted was one index higher than necessary. I've fixed that but in fact that did not affect the painting operation itself since it's limited to clipping area anyway. I have improved the logging at certain places in the code. http://hg.netbeans.org/jet-main/rev/055a1b05b40a I mark the issue as fixed. If there would be any more tips for improvements please file a new issue. Thanks.
Integrated into 'main-golden', will be available in build *201209190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/055a1b05b40a User: Miloslav Metelka <mmetelka@netbeans.org> Log: #95375 - NX remote: Very sluggish and error prone window painting - fixed painting line end index computation.