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.
[ BUILD # : dc62b7a3c4bb ] [ JDK VERSION : 1.6.* ] During the selection operation in the editor some kind of characters move their position, something like dancing really weird and awkward. Steps to reproduce: 1. Create a new main class (without any import); 2. Type this at main method, please don't import anything: Collections.EMPTY_LIST 3. Now put the cursor at the beginning of this statement, keep Ctrl + Shift pressed and start to move the selecting to your right pressing right key. Basically when you hit the third selection change you will see LIST string moves some pixels. Looks line this is happening for italic font types.
I will check this. Please note that I am not able to reproduce this on MacOSX. Switching to Linux for testing now.
I have tried the today's build with the following config: Product Version: NetBeans IDE Dev (Build 201004060201) Java: 1.6.0_15; Java HotSpot(TM) Client VM 14.1-b02 System: Linux version 2.6.31-20-generic running on i386; UTF-8; en_US (nb) Userdir: /home/david/.netbeans/dev And it seems to work fine WRT dancing when selecting. Tried in Java and C++ file. Can you please re-try with newer build? If seen again please reopen but please tell me more details, like the exact fonts used etc.
I tested again with follow instruction: Logger.getLogger(Test.class.getName()); I start to select from Logger and when the cursor hit get|Logger it dance. It just happen when selection with Ctrl + Shift. I reproduced it using font Monospaced, size 12. I use always the default configuration for font in my workstation. I am pretty sure the problem is with italic characters because caret need space between this characters and so they are moved to make this possible. -- Product Version: NetBeans IDE Dev (Build 100406-9ebad556ff8f) Java: 1.6.0_19; Java HotSpot(TM) Client VM 16.2-b04 System: Linux version 2.6.31-21-generic-pae running on i386; UTF-8; en_US (nb)
Michel, as I am not able to reproduce I am lowering the priority and please bring this issue to the NetCat people and ask whether someone can see this again. Ask the people to cast votes here if they can see it. If someone is able to reproduce please send as detailed system (and JDK) info as possible. BTW my JDK is 1.6.0_15 and yours is _19 - I am not sure whether that can make a difference. Do you use the default LAF? I have tried with Monospace 12 on Ubuntu 910 and it worked. BTW the default on my instance of Ubuntu is Monospace 13 where I could reproduce some other problems (e.g. the selected lines separated by one pixel white line).
Well, I tested it using Metal and GTK LAF and both are reproducible :( I will ask NetCATers for help and if possible I will try to record some winki to make this easier to test. Thanks a lot for your help.
Created attachment 96812 [details] Ogg sample video Just let me know if you can't see this video. Well, I tested it with this: Product Version: NetBeans IDE Dev (Build 100406-9ebad556ff8f) Java: 1.6.0_19; Java HotSpot(TM) Client VM 16.2-b04 System: Linux version 2.6.31-21-generic-pae running on i386; UTF-8; en_US (nb) in an new user dir importing anything from previous version.
I can view the video. Thanks a lot for capturing it. At least I know how it should look like.
Hm, in spite of having this great video I was not able to reproduce this. My source in Editor sometimes also kind of flashes when I move caret up and down because it looks like Editor forgets about all parsed elements and displays everything in black and after a while syntax coloring shows up again. This moves with the code few pixels to right and back but it's not what Michel showed us. I will keep my eyes open...
This happens to me as well. Here are some details I've seen: 1) It is also not restricted to Java. I see it in Ruby as well. 2) It is not just restricted to the line being selected or characters being selected. When my machine is running through the syntax highlighting of my larger files, I can watch individual lines doing this while the highlighting is being done. Therefore, I believe it is a syntax highlighting issue. 3) It is not restricted to italic fonts, although it is most visible with Italics due to the extra space they require. It also occurs when bolding characters. I use monospaced fonts almost exclusively so it is very easy to see when it happens. The first indication is that the space required for a character grows (which it shouldn't) and this appears to cause the shift. This may be tied to, or have the same root cause as #183447.
I've tried to reproduce on italic characters of various font sizes and it seems to work fine (likely resolved once the rounding issues were resolved).
I have just found that the problem can still be reproduced when using Lucida Console font. Reopening.
Due to selection the rendering splits an italicly rendered identifier into two parts (selected and non-selected) and two corresponding TextLayout objects. Being split they render wider since (due to italic font) they are like this |--/ and /--| instead of |----|. I need to change the rendering and also TextLayout caching in order to resolve this.
In current dev build 201007210001 I can see strange effects when selecting with Shift-left arrow over wrapped end of line (when "after words" wrapping is used). The chars wrapped on the next row are "moved" at the end of the previous row as long as they fit there.
Unfortunately the present fix is rather complex (140kB diff) and I still work on its stabilization. It would destabilize the M1 builds so I postpone it for now.
*** Bug 189333 has been marked as a duplicate of this bug. ***
I'm also seeing this issue with all builds after 20100822 at least in MacOSX. Builds 20100814 and prior to that one (using same preferences, same machine, same fonts (Monaco 13), same everything) works OK, so hope this helps to pinpoint the cause, because it's very annoying.
Finally I have a fix. The TextLayout is now constructed for a whole text covered by a particular font so the foreground/background colors change (caused e.g. by a selection) does not cause splitting of the TextLayout into several ones (like originally) which in turn could lead to different measurements (mainly for italic fonts and possibly certain ligatures in a font etc.). So now several views may share a single TextLayout. There could be minor issues e.g. with proper common ascent rendering when multiple fonts get mixed on a line etc. but they should be fixable. It was not easy to make things to render properly (since e.g. the TextLayout can only fully render so there needs to be a proper clipping done etc.) but it should work correctly now. It was also necessary to alter the views building process considerably so that now first the views get created and parented and their offsets properly set and then in a second round the text layouts and spans get computed. Also when replacing views on a line the adjacent views must be checked whether they share the same text layout as the view(s) being removed. In the end the change should be beneficial from a performance point of view as well since there is a less TextLayout objects being constructed now. http://hg.netbeans.org/jet-main/rev/781d41acc048
Thanks a lot for your hard work. I will verify it as soon as it hits the main repo today and give you any feedback I could. Thanks again
Created attachment 102566 [details] Moving caret still moves another words Now it is really better than before but there is still some problems. I attached the first image of two I had with examples of it. This first one sample during the move, when the carret is still passing through the italic word. The second will be after finish the selection.
Created attachment 102567 [details] Moving caret still moves another words, part 2 This is the second part of the move, when it finish to select. You can see some differences in the selection, some gaps are shown and so on. My doubt is if I should reopen it or file a new issue? Regards
Michel, I've noticed a similar problem too and I'm already working on it. I'll make an additional fix to this issue. Then if your case would still persist then we decide what next. Is your font (in the last note) Monospaced, size 12 or do you use any other font(s)?
Milo, I used to use Monospaced 12, as shown at Option dialog, but I today I noticed a strange behaviour. If I change the font size to 13 it looks the same, and if I turn it back to 12, it now is smaller than originally it was. Looks like in the truth I am using Monospaced 13 instead 12 even if it shows 12. Now, I am using it with size 13 but in both sizes I can see the exactly same behaviour when using the editor.
I have just fixed issue #191552 so the characters should no longer move upon selection at all.
(In reply to comment #23) > I have just fixed issue #191552 so the characters should no longer move upon > selection at all. Indeed it is now fixed, I just can't reproduce the original issue anymore, but the issue related to attachment http://netbeans.org/bugzilla/attachment.cgi?id=102567 is still valid. I will file a new issue about it. Thanks
Build 101103-10355c3c691f