How to enable antialiasing with monaco
Nico Weber
I accidentally found out how to enable antialiasing with Monaco, 10pt.
In Terminal.app, do
defaults write org.vim.MacVim AppleSmoothFixedFontsSizeThreshold 8
With that line, Monaco honors the value of 'antialias'.
As it turns out, OS X has two different thresholds for when a font
should be antialiased: For vector fonts, it uses the
AppleAntiAliasingThreshold default, which corresponds to the setting
in System Preferences, and which defaults to 8 (that means,
antialiasing is disabled if the font size is 8 or smaller). For pixel
fonts, OS X uses AppleSmoothFixedFontsSizeThreshold which defaults to
10 (ie fonts <= 10 are drawn aliased). This is because Apple's pixel
fonts are hand drawn up to font size 10.
Perhaps we want to include this in MacVim's Info.plist? Then
'antialias' would work as you'd expect (we could include both prefs
with a value of 0.01, then 'antialias' would work at all font sizes --
but I actually like that DejaVu Sans is antialiased and Monaco isn't.
Well, I guess I could set noantialias each time I switch fonts).
Nico
Mark Wilden
> defaults write org.vim.MacVim AppleSmoothFixedFontsSizeThreshold 8
>
> With that line, Monaco honors the value of 'antialias'.
Woo-hoo! It looks really sweet, now.
However, when I reinstalled MacVim to check it out, I still saw the
same problem with sluggish keyboard handling. Using j to move the
cursor down the screen goes in fits and starts (dependent on line
length?). And when I let up the key, the cursor keeps moving, as it
finishes up the queued keystrokes (the solution to which is, as I
mentioned, is simply to empty the buffer after processing a keystroke).
This is on a 361-line Ruby RSpec file - nothing special.
björn
My guess is that the "buffer" that is filling up with keystroke
messages is one used by the Distributed Objects (DO) system. This
would not be accessible via a public interface, so you can't simply
empty it after processing a keystroke.
I will look into this when I get a chance but please be patient.
Thanks,
Bjorn
Nico Weber
> same problem with sluggish keyboard handling. Using j to move the
> cursor down the screen goes in fits and starts (dependent on line
> length?).
How long are your lines? Does `:set wrap` or `:set nowrap` have an
effect? Can you post a screenshot of how your MacVim window looks when
you experience this behaviour (perhaps something comes to mind when I
see your environment).
Nico
Ben Schmidt
Hmmm. I see the problem now. Seems something in the Ruby syntax highlighting is
slowing it down. Other filetypes seem to be quicker, and :syntax off cures it.
Console Vim's (well, Terminal.app's) rendering is quicker so I think that's why
you don't see the problem there. I guess all the necessary context switching that
goes on between Vim and MacVim slows it down, plus possibly just the mechanism for
the rendering, too. Hmmm.
Ben.
Nico Weber
> I try to keep lines relatively short (< 144 chars), and wrapping
> doesn't seem to have an effect. Attached is a screenshot as well as
> the file (hope I'm doing this right).
I can see it now. The cause seems to be the 10pt font size (which
makes more lines visible: 153x100 chars on my display; with 12 pt
there are only 145x81 chars) combined with the ruby syntax file.
Scrolling other files (text files without syntax, c files) is faster,
but still slowish with a small font.
153x100 is only 15.300. If a character needs 4 bytes (cocoa uses utf16
for display, then we need display colors every now and then), that's
60kb per updates, or 1.2mb per second at 20 characters a second -- not
a lot. And normally, only about 4 bytes "scroll existing screen 1
line" plus 153*4 bytes should be needed per redraw. So it should be
possible that drawing is fast even with the IPC approach. Perhaps I'll
take a look at vim's drawing code when I have some more time
(hopefully in a few weeks).
Thanks for posting the issue.
Nico
ps: What colorscheme is that? Looks partially like vividchalk, but not
completely.
pps: Does anybody feel adventurous enough to try this with the new
regex engine that was posted at vim_dev and see if it improves the
ruby highlighting speed?
Mark Wilden
> Console Vim's (well, Terminal.app's) rendering is quicker so I think
> that's why
> you don't see the problem there.
Just to be clear, I'm using an old "Normal version with Carbon GUI,"
compiled Nov 2 2007 by jj...@jjgod-computer.local, not the GUI-less
Vim that comes with a Mac.
///ark
Mark Wilden
> ps: What colorscheme is that? Looks partially like vividchalk, but not
> completely.
It is vividchalk. Let me tell you a little story...
I've been developing on Microsoft systems since 1984. A couple of
years ago, I decided to follow the Pragmatic Programmers' advice and
learn a new language. Ruby seemed like a good choice, and eventually I
discovered how fun it was to write websites with Ruby on Rails
(compared to ASP.NET). So three months ago, I quit my job and went to
look for work as a RoR developer. It wasn't easy, but I finally landed
something, and I'm loving life. However, it seemed that all the cool
kids used Macs, and, in particular, this wonderful editor called
TextMate. I wanted to be a cool kid, too, so (after 24 years of
Microsoft/PCs) I switched to a Mac, more or less just so I could use
TextMate.
What a piece of crap. You can't even split windows! I blogged about it
as "the worst program people love that I've ever used." I absolutely
don't get how anyone who's used a real editor (vi, emacs, even Visual
Studio) could like it. Whatever. But I still wanted to at least
emulate the cool kids, so that's why I use vividchalk with Vim.
Just thought everyone would be interested. Or not. :)
> pps: Does anybody feel adventurous enough to try this with the new
> regex engine that was posted at vim_dev and see if it improves the
> ruby highlighting speed?
I'd be happy to, but there are probably much better people to do it. I
assume it involves building from C code, which I haven't done in a
long time. But if no one else volunteers, I'd love to give it a crack.
///ark
Jjgod Jiang
On Sat, Apr 19, 2008 at 12:58 AM, Mark Wilden <ma...@mwilden.com> wrote:
> Just to be clear, I'm using an old "Normal version with Carbon GUI,"
> compiled Nov 2 2007 by jj...@jjgod-computer.local, not the GUI-less
> Vim that comes with a Mac.
Unfortunately that's *not* MacVim but another Cocoa based implementation
by me, which is called vim-cocoa (I believe you downloaded that from
vim-cocoa.googlecode.com, right?) It described itself as "Carbon GUI"
which is wrong, src/version.c still remain to be updated.
I thought you're talking about MacVim at first I haven't follow your
discussions lately, I'll try look into this to see if it's reproducible on
my computer.
BTW: Download the latest version of MacVim from:
http://macvim.googlecode.com and see if it helps.
- Jiang
Mark Wilden
> On Sat, Apr 19, 2008 at 12:58 AM, Mark Wilden <ma...@mwilden.com>
> wrote:
>> Just to be clear, I'm using an old "Normal version with Carbon GUI,"
>> compiled Nov 2 2007 by jj...@jjgod-computer.local, not the GUI-less
>> Vim that comes with a Mac.
>
> I thought you're talking about MacVim at first I haven't follow your
> discussions lately, I'll try look into this to see if it's
> reproducible on
> my computer.
I know. I'm explaining why I'm -not- using MacVim (as much as I'd like
to).
I was just making clear that I'm also not using the Vim that comes
with OS X.
///ark
Jjgod Jiang
On Fri, 18 Apr 2008, Mark Wilden wrote:
> I know. I'm explaining why I'm -not- using MacVim (as much as I'd like
> to).
>
> I was just making clear that I'm also not using the Vim that comes
> with OS X.
OK.. I misunderstood your last mail.
- Jiang
björn
I just tried setting the above defaults in Info.plist but I still get
aliased Monaco 10 (same thing happens if I try to set these defaults
in +[MMAppController initialize] where I set all other defaults). If
I set the defaults with "defaults write org.vim.MacVim ..." then it
works. I'm kind of stumped as to why this happens, any ideas?
Björn