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.

Bug 106940 - Scrolling is broken on dual-monitor
Summary: Scrolling is broken on dual-monitor
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 6.x
Hardware: PC All
: P2 blocker (vote)
Assignee: David Simonek
: 95953 110991 (view as bug list)
Depends on:
Reported: 2007-06-17 17:16 UTC by kirillkh
Modified: 2011-06-09 09:56 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description kirillkh 2007-06-17 17:16:10 UTC
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.
Comment 1 Maros Sandor 2007-06-18 09:54:54 UTC
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.
Comment 2 kirillkh 2007-06-18 17:25:32 UTC
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
     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.
Comment 3 kirillkh 2007-06-18 17:35:49 UTC
s/while the window is at fullscreen/while the window is maximized/
Comment 4 kirillkh 2007-06-19 07:51:47 UTC
(forgot to mention that all these things were happening with a 070618 build)
Comment 5 kirillkh 2007-06-19 08:00:52 UTC
2 people on nbusers reported the issue is reproducible in 5.5.1. One of them confirmed he's running a dual-monitor setup.
Comment 6 Maros Sandor 2007-06-19 09:22:12 UTC
I will try to reproduce using your steps.
Comment 7 kirillkh 2007-06-19 10:45:33 UTC
Please note that this is probably not specific to CVS, since it happened in Files view without me doing anything with CVS.
Comment 8 Maros Sandor 2007-06-19 10:49:31 UTC
Ok then, can you reproduce it also without using Diff?
Comment 9 kirillkh 2007-06-19 11:20:27 UTC
I can, please see part (I) in the steps.
Comment 10 Maros Sandor 2007-06-19 12:29:03 UTC
Reassigning for evaluation, see steps to reproduce I.
Comment 11 Milos Kleint 2007-06-19 13:12:08 UTC
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
Comment 12 kirillkh 2007-06-20 14:34:49 UTC
Got input from the second person on nbusers, he's also experiencing it with a dual-monitor setup.
Comment 13 kirillkh 2007-06-25 12:07:58 UTC
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.
Comment 14 David Simonek 2007-06-25 12:56:59 UTC
kirillkh, in order to fix this issue, we have to know where the problem is - JDK? Swing? NetBeans? Your graphics card

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)
Comment 15 kirillkh 2007-06-26 12:28:36 UTC
-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
Comment 16 Stanislav Aubrecht 2007-06-28 13:44:31 UTC
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)
Comment 17 kirillkh 2007-06-28 14:09:06 UTC
Did you mean *shorter* side up? Anyway, my monitor doesn't even support rotation.
Comment 18 David Simonek 2007-07-25 13:23:35 UTC
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...
Comment 19 kirillkh 2007-07-25 13:29:24 UTC
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.
Comment 20 David Simonek 2007-07-25 13:42:12 UTC
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. 
Comment 21 jmakiman 2007-07-25 15:56:56 UTC
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.
Comment 22 Peter Pis 2007-07-26 12:08:54 UTC
*** Issue 110991 has been marked as a duplicate of this issue. ***
Comment 23 Peter Pis 2007-10-29 13:06:33 UTC
*** Issue 95953 has been marked as a duplicate of this issue. ***
Comment 24 kirillkh 2007-10-29 15:27:25 UTC
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.
Comment 25 Marian Mirilovic 2011-06-09 09:56:17 UTC