Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 183219 - [69cat] The characters move theirs position during selection
[69cat] The characters move theirs position during selection
Product: editor
Classification: Unclassified
Component: Painting & Printing
PC Linux
: P3 with 1 vote (vote)
: 7.0
Assigned To: Miloslav Metelka
: 189333 (view as bug list)
Depends on: 191257
  Show dependency treegraph
Reported: 2010-03-30 19:55 UTC by Michel Graciano
Modified: 2010-11-03 11:42 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT

Ogg sample video (184.38 KB, video/ogg)
2010-04-06 20:14 UTC, Michel Graciano
Moving caret still moves another words (2.32 KB, image/png)
2010-10-22 11:27 UTC, Michel Graciano
Moving caret still moves another words, part 2 (2.52 KB, image/png)
2010-10-22 11:29 UTC, Michel Graciano

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Graciano 2010-03-30 19:55:45 UTC
[ 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:
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.
Comment 1 David Strupl 2010-04-06 08:22:08 UTC
I will check this. Please note that I am not able to reproduce this on MacOSX. Switching to Linux for testing now.
Comment 2 David Strupl 2010-04-06 08:56:18 UTC
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.
Comment 3 Michel Graciano 2010-04-06 13:50:45 UTC
I tested again with follow instruction:


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)
Comment 4 David Strupl 2010-04-06 18:43:53 UTC
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).
Comment 5 Michel Graciano 2010-04-06 19:12:48 UTC
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.
Comment 6 Michel Graciano 2010-04-06 20:14:51 UTC
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.
Comment 7 David Strupl 2010-04-06 20:33:53 UTC
I can view the video. Thanks a lot for capturing it. At least I know how it should look like.
Comment 8 Jiri Kovalsky 2010-04-07 21:04:31 UTC
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...
Comment 9 esmithbss 2010-04-08 14:43:30 UTC
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.
Comment 10 Miloslav Metelka 2010-06-24 12:22:52 UTC
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).
Comment 11 Miloslav Metelka 2010-06-24 12:35:25 UTC
I have just found that the problem can still be reproduced when using Lucida Console font. Reopening.
Comment 12 Miloslav Metelka 2010-06-24 12:50:27 UTC
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.
Comment 13 Tomas Pavek 2010-07-21 13:04:27 UTC
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.
Comment 14 Miloslav Metelka 2010-08-10 13:50:35 UTC
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.
Comment 15 Miloslav Metelka 2010-08-11 09:44:04 UTC
*** Bug 189333 has been marked as a duplicate of this bug. ***
Comment 16 arcnor 2010-09-24 10:45:50 UTC
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.
Comment 17 Miloslav Metelka 2010-10-21 08:06:45 UTC
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.
Comment 18 Michel Graciano 2010-10-21 11:23:45 UTC
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
Comment 19 Michel Graciano 2010-10-22 11:27:45 UTC
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.
Comment 20 Michel Graciano 2010-10-22 11:29:43 UTC
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?

Comment 21 Miloslav Metelka 2010-10-22 14:46:22 UTC
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)?
Comment 22 Michel Graciano 2010-10-22 15:05:22 UTC
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.
Comment 23 Miloslav Metelka 2010-11-02 09:57:28 UTC
I have just fixed issue #191552 so the characters should no longer move upon selection at all.
Comment 24 Michel Graciano 2010-11-03 11:42:11 UTC
(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 is still valid. I will file a new issue about it.

Comment 25 Michel Graciano 2010-11-03 11:42:56 UTC
Build 101103-10355c3c691f

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo