Random taints appear on screen using ATSUI renderer

[GoogleCodeExporter]

[What steps will reproduce the problem?]

I think it has been there since it implemented ATSUI renderer but launch 
snapshot 47.
Load a dark background color like 'desert'.
Set the font size to 14. (It seems to default to Dejavu Sans Mono, so, use that 
if it isn't selected)
Just to be sure, I used 'set guifont=*' and picked it.
Move around the file back and forth.

[What is the expected output? What do you see instead?]

Sooner or later you should start to see short lines at the bottom of the screen 
that looks like 
they weren't wiped off on display redraw upon scrolling.
These can be cleared with 'ctrl-l' (Thats lowercase L) but keeps appearing as I 
move around the 
file.

Also, if you turn line wrapping off with 'set nowrap' and go to end of line '$' 
and scroll up and 
down if the file has line width that is bigger than the macvim screen width, 
they start to appear 
between lines too.

[What version of MacVim and OS X are you using (see "MacVim->About MacVim" and  
"Apple 
Menu->About This Mac" menu items, e.g. "Snapshot 40, 10.5.6 Intel")?]

OS X 10.5.7 Intel
Snapshot 47

[Please provide any additional information below.]

This does not appear once ATSUI renderer is disabled.

My short observation shows that these come from letters like underscore '_' 
that they seem to 
exist outside the size of regular alphabets and they never get wiped off on 
scroll and are left 
where they were.

As you can see on the 2 attached screenshots, the redundant lines shown on the 
second picture 
corresponds to the underscore that is on the same line but at the more earlier 
part of the line on 
the first picture. But in other occasions, it also happens on other sign 
characters that seem to be 
bigger than regular alphabets and are left as dots.

Original issue reported on code.google.com by h...@live.com on 20 Jul 2009 at 9:31

Attachments:

• atsui-taint1.png
• atsui-taint2.png

[GoogleCodeExporter]

Thanks for the report.

I'm aware of these types of problems with the ATSUI renderer.  The problem is 
with glyphs which extend "too 
low" or (more rarely) "too high" and then antialiasing causes it to "bleed" 
outside its bounding box.  I'll take 
another look -- it may be possible to just raise the baseline by 1px to avoid 
the worst problems but this is a 
hard problem to solve since Vim assumes that no glyph extends outside its own 
bounding box.

Usually the best workaround is to find another font/size combination which 
avoids the problem, or to use the 
default renderer. :/

Original comment by bjorn.winckler@gmail.com on 20 Jul 2009 at 11:38

[GoogleCodeExporter]

Would it be possible to implement to auto trigger 'ctrl-l' to wipe them upon 
when scrolling stops if it cannot be 
fixed? Although it seems a vim script should be used to do that instead, except 
I don't know much about it...

I like it that ATSUI renders fast and scrolls fast and even renders letters 
more beautifully ;) I've been feeling too 
bad about this problem for quite a while and has been using default renderer. 
It would be hard to switch 
font/size that I'm accustomed to.

Thanks for the response.

Original comment by h...@live.com on 20 Jul 2009 at 12:07

[GoogleCodeExporter]

That sounds like too much of a hack...not something I'd want to do.

I do think I've come up with another temporary workaround.  Try setting 
linespace like this

:set linespace=1

That takes care of problems with underscores for me.  It does make every line 
1px higher, which may or may 
not be acceptable to you.  Try it out and let me know what you think.  Of 
course, I'll still try and find a proper 
fix for this problem.

Original comment by bjorn.winckler@gmail.com on 20 Jul 2009 at 4:34

[GoogleCodeExporter]

Wow, it nearly fixed it. Thanks for the tip.
I'm using BPmono:h17 and mostly looking good.

The only one I just found on this file is that 'd' in italic seems to leave a 
trail of it's upper bit when screen 
scrolls horizontally.

But for now I think I can use ATSUI and just manually wipe the left overs with 
'ctrl-l' once in a while.

Original comment by h...@live.com on 20 Jul 2009 at 4:49

[GoogleCodeExporter]

Also, I just used linespace=10, and it still seems those 'italic d' leaves it's 
trail.
So, it's only good to increase from 0 to 1, but does not get it better by 
increasing it further.

Hopefully there would be an universal solution in the future.

Original comment by h...@live.com on 20 Jul 2009 at 4:52

[GoogleCodeExporter]

OK, this problem is mostly fixed now.  What I do is I clip the text to the rect 
where Vim thinks everything should 
fit (the reason it sometimes doesn't fit is because of antialiasing).  This may 
cause some glyphs to look "chopped 
off" but that seems to be the lesser of two evils.

You'll need to build your own version to try this out, the instructions on how 
to do this are on the Wiki.  
Otherwise you can just wait for the next snapshot (but that may be a couple of 
weeks since I just released snap 
47).  (If you do go ahead and build your own [and feel adventurous] then you 
may even want to try the feat/core-
text branch as it is roughly twice as fast as the ATSUI renderer.)  Let me know 
how it goes if you try it out.

Original comment by bjorn.winckler@gmail.com on 20 Jul 2009 at 6:20

[GoogleCodeExporter]

Thanks for quick fixes.

I've tested both the new ATSUI one and the core-text one and yes, it's 
certainly better to just see them gone 
in the first place than have them leave trails all over. So, I guess that's a 
great improvement over the ATSUI 
rendering version.

The core-text one seems a totally different rendering, the fonts and even 
background colors look very 
different (as in contrast) but it is surely fast, the scrolling is as smooth as 
it can be. It said that this version  
has some display problems but what are they? If it's not critical, I might want 
to use this one for the time 
being.

Original comment by h...@live.com on 21 Jul 2009 at 2:31

[GoogleCodeExporter]

On the core-text branch, I just noticed that I cannot input multi byte 
characters at all.
Usually I can flip the input methods and type in them directly under insert 
mode, but it seems this branch 
always inserts exactly as I type. Would this be easy to fix? Thanks.

Original comment by h...@live.com on 21 Jul 2009 at 7:59

[GoogleCodeExporter]

It amazes me that you can see such differences in the rendering between 
ATSUI/CoreText/Cocoa.  How 
exactly do you tell the difference?  Are you rendering "complex" glyphs or just 
plain ASCII?  Do you find the 
Core Text rendering worse in any way?  Could you upload some details of a 
screenshot which highlights the 
difference?

Anyway, I have not yet gotten around to implementing "marked text" handing for 
the Core Text renderer but I 
think that would not be too hard to fix.  Also, if you often edit with 
different input methods you may want to 
try the feat/input branch -- check out my post to vim_mac describing what it 
does:

http://groups.google.com/group/vim_mac/browse_thread/thread/4d5a957e8b8ba214

(As I outline in that post I'd like some more people testing that branch which 
is why I mention it here.)

The most blatant problems with the CT renderer is using the mouse to resize 
window (flickers a bit), typing 
":set go+=r", entering full screen mode (Window-> Toggle Full Screen Mode).  
There are sure to be more 
problems, if/when you find them please let me know (maybe start a separate 
issue report).

Original comment by bjorn.winckler@gmail.com on 21 Jul 2009 at 8:19

[GoogleCodeExporter]

Oh, for my settings, the differences were very noticeable, although while I 
felt the CT to have more squashed 
texts, a moment later I figured I liked it better than regular or ATSUI. But 
the ATSUI font rendering looks 
superb though.

Now that I have tasted ATSUI and CT rendering speed, I really don't want to go 
back to regular one. Feels like 
crawling while scrolling around a file after getting used to the smoothness.

Here are the screenshots for each of the rendering engines. (I'm using a 
modified 'freya' color scheme, I'll 
post it if you ever need that, and BPmono font, which is freely avaiable at its 
site. Or if my .[g]vimrc has 
anything to do with making the rendering look different across engines, I can 
post them too.)

" E.g. you can use a US layout in normal mode and your native layout in insert 
mode. "

This is great! =) I often felt awkward that I kept typing in multibyte letters 
under control mode, only having 
have to press Esc and switch back to US layout and continue working...and of 
course switch it back again if I 
was going to input multi byte characters.

I'll test this branch later. Thanks for the inputs.

Original comment by h...@live.com on 21 Jul 2009 at 9:03

Attachments:

• macvim-regular.png
• macvim-atsui.png
• macvim-coretext.png

[GoogleCodeExporter]

I just tested the input branch build and tried to use the 'remember input mode 
on command/insert mode' 
feature but after I entered insert mode and flipped the input method and typed, 
the input method 
automatically flips back to alphabets, which is probably not as convenient, as 
I will have trouble typing in multi 
byte characters consecutively. Also the input methods are not remembered when I 
exit insert mode, but that 
could be because the input methods turns into alphabets as soon as I finish 
typing in multi byte characters.

I did use 'set noimd' but did I do something wrong?

Original comment by h...@live.com on 22 Jul 2009 at 10:13

[GoogleCodeExporter]

I'm not sure what's happening.  Here's how it works for me:

1. open new window, keyboard layout is US, :set noimd
2. enter insert mode, choose Katakana from the OS X input menu (next to the 
clock) and enter Katakana, the 
input source will stay as Katakana and not switch back so I can type "ka", hit 
Enter, then keep typing Katakana
3. hit Esc to go back to normal mode, then OS X input source automatically goes 
back to US (US flag shows on 
menu bar again)
4. enter insert mode and the input source goes back to Katakana until I exit 
insert mode (or manually change 
it by selecting another source from the menu)

Is that not how it works for you?  If not, give me step-by-step instructions on 
what you type (which input 
source do you use?).

Original comment by bjorn.winckler@gmail.com on 22 Jul 2009 at 11:10

[GoogleCodeExporter]

ok. I'm using Kotoeri. I still cannot seem to do what you describe.

But is it because I only use Kotoeri and not the US layout? The only options 
checked on the input menu system preference are 
'Kotoeri', 'Hiragana' and 'Romaji'. Since Romaji provides English typing, I do 
not have US layout enabled.

What I did was,
- Do 'set noimd'.
- Go insert mode, flip to 'Hiragana', type 'にほんご' and hit Enter. At 
this moment, the input method automatically reverts to 
Romaji, so going out of insert mode will always be Romaji.

---

I just enabled US layout as well, but I'm kind of confused at the moment.
And I just found something interesting, but if I just type 'ka' to give 'カ' 
alone, the input method stays, but as soon as I type 'kata' 
for  'カタ', the input method reverts to US layout after hitting Enter. Also, 
adding another letter to the first 'カ' would revert back 
as well, so I think it will only keep 'Katakana' as long as the typing ends on 
the first letter of the line. And when I hit 'Esc', it will 
go back to US layout after typing single 'カ' but it won't give me 'katakana' 
input method after I go back to insert mode.

Which input methods do you have enabled?

Original comment by h...@live.com on 22 Jul 2009 at 11:29

[GoogleCodeExporter]

Just a guess, sorry if you already knew but there's a MacVim variant of Kaoriya 
I just found looking through the 
git repository and they are targetting for people using Japanese, so they may 
have good understandings of the 
problems.

Original comment by h...@live.com on 22 Jul 2009 at 11:32

[GoogleCodeExporter]

I just tried only having Kotoeri (no US) enabled and it still won't flip to 
Romaji for me, until I exit insert mode 
that is.  It should _never_ flip automatically until you change modes -- so 
while in insert mode it should stay 
as whatever source you choose manually.

Please do this for me:

1. quit MacVim
2. Open terminal and type "defaults write org.vim.MacVim MMLogLevel 7"
3. open MacVim, do a quick session with 'noimd' where it flips back to Romaji 
in insert mode and quit MacVim
4. Open Console.app, search for "Vim" in top left corner and copy/paste the 
logs into a text file, save it, zip it 
and email it to me directly
5. Reset log output level by opening terminal and type "defaults write 
org.vim.MacVim MMLogLevel 5"  (5 
instead of 7)

Thanks.

I did see Kaoriya but I don't know that much about it.  Don't think they've 
fixed the IM problem though.

Original comment by bjorn.winckler@gmail.com on 22 Jul 2009 at 11:44

[GoogleCodeExporter]

Before doing all that, could you just give me a list of all your environment 
variables.  Assuming you are using the 
default shell, just open Terminal and type "export".  Just copy&paste the 
output.  Thanks!

Original comment by bjorn.winckler@gmail.com on 22 Jul 2009 at 5:06

[GoogleCodeExporter]

Also, to make sure no vimrc or plugins are interfering, please try temporarily 
renaming your .vimrc/.gvimrc files 
and .vim folder then restart.  Does it still switch to Romaji after entering 
some Katakana?  If it doesn't, try 
figuring out which setting/plugin is causing the problem.  Thanks again.

Original comment by bjorn.winckler@gmail.com on 22 Jul 2009 at 5:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sorry for being late.
After I tried again... mysteriously the auto flipping ceased to repeat.
But then, if I escape from insert mode with katakana mode, it will not go back 
to romaji mode for alphabet 
typing.

I do not think my variables are anything unique but here it is.

Apple_PubSub_Socket_Render=/tmp/launch-hbnzIE/Render
COMMAND_MODE=unix2003
DISPLAY=/tmp/launch-1fdq3I/:0
HISTFILE=/Users/me/.zsh_history
HISTSIZE=10000
HOME=/Users/me
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
LC_CTYPE=UTF-8
LOGNAME=me
LSCOLORS=CxHxCxDxBxegedabagacad
MANPATH=/opt/local/man:/usr/share/man:/usr/local/share/man:/usr/share/man:/usr/l
ocal/share/man:/us
r/X11/man
MBOX='~/.mbox'
OLDPWD=/Users/me
PAGER=less
PATH=/opt/local/bin:/var/lib/gems/1.8/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/loc
al/bin:/usr/X11/bin
PROMPT='%{%}%n%{%}@%{%}%m > %{%}'
PWD=/Users/me
RPROMPT='%{%}%~ %{%}[%D{%R}]%{%}'
SAVEHIST=10000
SECURITYSESSIONID=912a70
SHELL=/bin/zsh
SHLVL=1
SSH_AUTH_SOCK=/tmp/launch-ECZ1We/Listeners
TERM=xterm-color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=240.2
TMPDIR=/var/folders/2R/2R4kKmppE98dYsg24C94FU+++TI/-Tmp-/
USER=me
WORDCHARS='*?~&#$%^'
__CF_USER_TEXT_ENCODING=0x1F5:0:0

Original comment by h...@live.com on 25 Jul 2009 at 11:00

[GoogleCodeExporter]

Thanks for the env vars...I tried matching yours but it still works flawlessly 
for me.

As for why it doesn't go back to Romaji when Esc:aping from insert mode:  You 
didn't forget to ":set noimd" 
by any chance?  (Silly question, but still...)

Also, when you check out a new branch you should "make clean" first, and also 
clean the Xcode project by "rm 
-rf build" inside "src/MacVim".  Weird things have been known to happen 
otherwise.

I'm still interested if your .vimrc/.gvimrc files .vim folder may be causing 
problems.  You should try renaming 
them and restarting to see if the problem persists.

Original comment by bjorn.winckler@gmail.com on 25 Jul 2009 at 1:21

[GoogleCodeExporter]

ok... i'm sorry for confused reports... (knocks my head) the last report was 
faulty, that was without 'set 
noimd'... but as soon as I set that, now that the input method flips back like 
it did earlier. And this time I've 
removed .vimrc, .vim, .gvimrc and it works like you described.

The bad config was 'set iminsert=0'. I probably set that one day thinking it 
would help in some way...
Once that was removed, everything is good.

Original comment by h...@live.com on 25 Jul 2009 at 2:12

[GoogleCodeExporter]

Excellent!  I'm glad it works.  Let me know if you come across any problems 
(even if there are no problems I'd 
like to know what you think of it).

I started looking at "marked text" support in the Core Text renderer and it is 
a little bit complicated.  Instead 
of hacking together some support I decided to look into getting proper support 
where the text is actually 
drawn by Vim (it works this way on GTK2 with XIM if I understand things 
correctly).  However, this is a big 
project which I don't think I will be able to complete for a while.

I do have a super basic patch that lets you enter marked text but you can't use 
the cursor keys to move 
through it and with some other problems.  If you are interested I can send this 
patch your way though as it 
will enable you to use the Kotoeri input source at least.

Original comment by bjorn.winckler@gmail.com on 25 Jul 2009 at 2:47

[GoogleCodeExporter]

Ah, ok. I could give the patch a try =) Thank you.

Original comment by h...@live.com on 25 Jul 2009 at 4:03

[GoogleCodeExporter]

I've updated the feat/core-text branch to include the updated marked text 
patches. 
So now you can use Kotoeri etc. with the Core Text renderer as well.

I'll close this issue now.  If any of the issues originally reported persist 
then
please start a new issue.

Original comment by bjorn.winckler@gmail.com on 15 Aug 2009 at 11:54

• Changed state: Fixed