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.
Product Version: NetBeans IDE Dev (Build 070612) Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) --------------------- 1. open a Java source file 2. modify and diff it result: now scrolling in any editor view, including Diff window, behaves very strangely: 1. when you scroll up, only the top three lines of the editor are redrawn 2. when you scroll down, only the bottom three lines of the editor are redrawn I haven't figured a way to cure the problem, except restarting the IDE.
I cannot reproduce the problem here, can you try some of the newer builds, please? If the problem persists across builds then please try to delete your userdir and reproduce the problem with fresh setup.
I. Reproduced with a new user dir. 1. start the IDE 2. open the project 3. go to Files view 4. the scrolling problem happens in the Files view now Seems to only happen on my secondary screen and only when the vertical window size exceeds the vertical size of the primary screen (didn't check, if it also happens, when the window is smaller than the primary screen, but positioned at coordinates exceeding 768x1024). II. restored the original user dir, tried to reproduce again. 1. couldn't reproduce in the Files view 2. couldn't reproduce the originally reported problem with diffing, while the window is at fullscreen 3. after trial-and-error, managed to reproduce it on the secondary screen, when the main window is not maximized 4. things that made the scrolling work and stop working: 4.1. obscuring part of the diff view with another window made it work. removing the obscuring window made it broken again 4.2. moving the window right and left: looks like the problem only happens, when the left border of the editable (white) part of the right half of the Diff panel has absolute horizontal screen coordinate at >=~785 pixels 4.3. moving the window right to the point, where a (small) part of the window border was showing on the primary screen III. after writing the first two sections, I closed the Diff view (while the window was still not maximized) and could reproduce the problem in a Java editor. There also was a horizontal sweet point, this time at >=~430 pixels for the editable part of the source view. My machine is Dell Latitude D505 laptop with an external monitor attached to it. The laptop monitor is configured in Windows as the primary screen, the external monitor is configured to "extend" the desktop to the left. The resolution of the laptop screen is 1024x768, external screen - 1280x1024.
s/while the window is at fullscreen/while the window is maximized/
(forgot to mention that all these things were happening with a 070618 build)
2 people on nbusers reported the issue is reproducible in 5.5.1. One of them confirmed he's running a dual-monitor setup.
I will try to reproduce using your steps.
Please note that this is probably not specific to CVS, since it happened in Files view without me doing anything with CVS.
Ok then, can you reproduce it also without using Diff?
I can, please see part (I) in the steps.
Reassigning for evaluation, see steps to reproduce I.
since it appears to happen with diff, editors and the files view it's most probably something in our winsys or even swing. -> core/windowsystem
Got input from the second person on nbusers, he's also experiencing it with a dual-monitor setup.
Can we get this fixed? It's happens to me all the time and is very annoying. Many people are seeing the problem, and there's at least one person who experiences this on a single monitor setup.
kirillkh, in order to fix this issue, we have to know where the problem is - JDK? Swing? NetBeans? Your graphics card driver? Please try following things: - try to reproduce with various JDK versions - try to reproduce with other java apps, like SwingSet2 demo - try to disable DirectDraw acceleration, run NB with -J-Dsun.java2d.noddraw=true (or SwingSet2 with -Dsun.java2d.noddraw=true)
-reproduced with jdk 1.6.0 and 1.6.0_01 -can't reproduce with SwingSet2 -can't reproduce in 1.6.0_01 after disabling ddraw
i wasn't able to reproduce this on jdk1.5/1.6, win xp kirillkh, would you by any chance have your monitor in pivot mode? (the longer side up)
Did you mean *shorter* side up? Anyway, my monitor doesn't even support rotation.
quoting reporter: "-can't reproduce in 1.6.0_01 after disabling ddraw" That's it - it is one of these JDK bugs with direct draw, workaround is to not use ddraw. Nothing we can do about this on NetBeans side, sorry...
Considering there were no such issues formerly (even in the first 6.0 milestones), one would suppose a workaround on NB's part should be possible.
I'm really sorry, but such workaround is out of my knowledge and possibilities - real reason for this JDK bug to start occurring may be one of millions repaints or relayouts in tons of netbeans code. I have absolutely no chance to chase this down, and I think nobody from netbeans team/community has...sadly it's up to JDK folks. Problem is that such repaint errors are almost always unreproducible - on different machine it will behave differently for sure.
Sorry to hear that. I'll have to turn off dual monitor then. This may come out to be a significant reason for other users to switch to Eclipse or IntelliJ. Those IDEs work fine with dual monitor - at least on my Windows XP system. In my case, I'll continue to use and explore Netbeans for a while.
*** Issue 110991 has been marked as a duplicate of this issue. ***
*** Issue 95953 has been marked as a duplicate of this issue. ***
I think it shouldn't really be that hard to find what triggers the issue. We know that it used to work in earlier NB6 builds and then broke. Once you reproduce the issue in your environment, it should be sufficient to do a binary search on several months' daily builds. What I suggest is: 1. let START := an arbitrarily old date (say, Jan 2007), make sure DAILY_BUILD(START) doesn't exhibit the problem 2. let END := June 2007 (which, as we know, exhibits the problem) 3. let MID := the middle of the period (April in this case) 4. check, whether DAILY_BUILD(MID) exhibits the problem: 4.1. if it does, END := MID 4.2. otherwise, START := MID 5. repeat starting from step 3 The complexity is log2(N), where N is around 180 days (as in 1/2 of a year). This gives ~7.5 iterations to narrow it down to one daily build in the worst case. After that, you should be able to find the offending commit and work around it.
v/c