Early Core Text renderer patch

[björn]

Hi all,

Several months ago I started writing a new renderer using Core Text
but I never had the time to finish it and it has been lying dormant
since then. Today I decided to revive this patch and I am hoping some
people will try it out and give me some feedback. Please note that
the patch is experimental.

Benefits:
- faster (in the test cases I've run a profiler it can be up to 4 times faster)
- better rendering support of utf8, e.g. some (all/most?) composing
characters work
- support for undercurls
- modeless selection works better (try it when you have started typing
a :-command)
- from my perspective the code is much easier to understand/maintain
and it fits better with the Vim drawing model

Problems I can think of right now:
- flickers when resizing window
- full-screen support is flaky
- drawing artifacts (if a glyph spills outside its display cell then
it will leave ghost pixels behind)
- only works work with Mac OS X 10.5

The patch is attached to this post.

I understand a lot of people don't want to bother with applying
patches so I've uploaded a binary build as well to:

http://bjorn.winckler.googlepages.com/MacVim-CT-Leopard-x86-090328.tar.bz2

NOTE! The binary runs on Intel Macs with OS X 10.5 only! This is not
a snapshot -- use only for testing purposes.

Björn

[Yvonne Thomson]

Hi.

My first comment on this is eeeeek!! Mostly because with this patch,
VoiceOver suddenly can't see the text area of the editor. In other
words, I can't see what I'm typing, the same way it is with textmate,
bbedit and the rest.

I don't know if anything can or would be done about this, and I know
I'm a minority user, but I thought I'd give some feedback anyway.

[björn]

2009/3/29 Yvonne Thomson:

Hi Yvonne,

Yes that is a problem but I am not planning on abandoning the old
renderer so you will always be able to still use that one. There may
very well be some other features offered by the Cocoa text system that
will no longer work with the Core Text renderer as well.

Thanks for pointing this out.

Björn

[Tom McNulty]

Hi Björn,

Why not create a branch in your git repo? That'll way it'll be a bit
easier for us to follow your changes.

I applied the patches to the current head and loaded up a file full of
UTF-8 text. To compare performance I used snapshot44 as a baseline.
While I do see some of the artifacts you mention, it's definitely
significantly faster. I get a slight speedup in s44 using ATSUI (with
less severe artifacts), but it is still not as fast as your renderer
patch.

Turning on/off the ATSUI renderer in the patched version doesn't seem
to make any difference, perhaps your patch disables ATSUI?


- Tom

[björn]

2009/3/29 Tom McNulty:

>
> Why not create a branch in your git repo? That'll way it'll be a bit
> easier for us to follow your changes.

I could do that, but I rebase that branch all the time -- would this
not cause problems?

> I applied the patches to the current head and loaded up a file full of
> UTF-8 text.  To compare performance I used snapshot44 as a baseline.
> While I do see some of the artifacts you mention, it's definitely
> significantly faster. I get a slight speedup in s44 using ATSUI (with
> less severe artifacts), but it is still not as fast as your renderer
> patch.

Thanks for trying it out!

> Turning on/off the ATSUI renderer in the patched version doesn't seem
> to make any difference, perhaps your patch disables ATSUI?

It is not possible to enable the ATSUI or the Cocoa renderers in the
current patch. I will address this later on.

Björn

[Tom McNulty]

>
> 2009/3/29 Tom McNulty:
>>
>> Why not create a branch in your git repo? That'll way it'll be a bit
>> easier for us to follow your changes.
>
> I could do that, but I rebase that branch all the time -- would this
> not cause problems?

It may upset contributers, but otherwise forcing a push on your side
will simply result in (automatic) forced pulls for us. I take it
you're rebasing these patches against the mainline?

>
>> Turning on/off the ATSUI renderer in the patched version doesn't seem
>> to make any difference, perhaps your patch disables ATSUI?
>
> It is not possible to enable the ATSUI or the Cocoa renderers in the
> current patch. I will address this later on.

Okay, my main concern was that I was testing your code, and not
accidently running the ATSUI renderer. Since I could see no difference
turning it on/off, I assumed it had been removed.


Thanks for your hard work.



>
>
> Björn
>
> >

[björn]

2009/3/30 Tom McNulty:

>>> Why not create a branch in your git repo? That'll way it'll be a bit
>>> easier for us to follow your changes.
>>
>> I could do that, but I rebase that branch all the time -- would this
>> not cause problems?
>
> It may upset contributers, but otherwise forcing a push on your side
> will simply result in (automatic) forced pulls for us. I take it
> you're rebasing these patches against the mainline?

Yes, I rebase it against my master branch which is the one I push to
the public repo. So, I guess this won't be an issue since I'm not
really expecting many people to be contributing to my experimental
branches (such as Core Text). If anybody ever does then I guess they
will have to take care.

I guess I should be able to name all experimental branches
"experimental/branchname" or something and then note down somewhere
that such branches get rebased onto master regularly. Hmmm...now how
do I do that...does "git branch experimental/name" work...have to take
a look. Maybe there is a more succinct standard name for this kind of
stuff..."topic/name" perhaps? Anybody with a clue?

Björn

[Tom McNulty]

unstable, testing, experimental, volatile, should all get the point
across. I have a hard time believing someone would complain about the
unstable branch lacking stability.


- Tom

[björn]

2009/3/31 Tom McNulty:

>
> unstable, testing, experimental, volatile,  should all get the point
> across. I have a hard time believing someone would complain about the
> unstable branch lacking stability.

I settled on "feat/" as it is short and sweet. :-)

I've pushed the "feat/core-text" branch to the repo now and added a
note stating that branches prefixed with "feat/" will be rebased
against master. I might start using public "feat/" branches more
liberally now so that people can see what I am working on at the
moment (nothing apart from feat/core-text right now).

Björn

[Nikola Knežević]

On 5 Apr 2009, at 16:00 , björn wrote:

> I've pushed the "feat/core-text" branch to the repo now and added a
> note stating that branches prefixed with "feat/" will be rebased
> against master. I might start using public "feat/" branches more
> liberally now so that people can see what I am working on at the
> moment (nothing apart from feat/core-text right now).

Hi Bjorn,

thanks for this patch. MacVim feels much snappier now. There are some
artifacts (like empty rectangles at the beginning of the line), but
that's what you said is going to happen :)

I had a problem during the first run, MacVim wouldn't honor Cmd+W, but
after subsequent runs, everything is fine to that regard.

Thanks,
Nikola

[björn]

2009/4/6 Nikola Knežević:

>
> thanks for this patch. MacVim feels much snappier now. There are some
> artifacts (like empty rectangles at the beginning of the line), but
> that's what you said is going to happen :)

I've pushed an update to feat/core-text branch which hopefully takes
care of the most obnoxious drawing artifacts. If anybody tries it out
be sure to let me know if things have improved and what problems are
still there.

> I had a problem during the first run, MacVim wouldn't honor Cmd+W, but
> after subsequent runs, everything is fine to that regard.

That's probably nothing to worry about, but let me know if it happens again.

Björn

[Nikola Knežević]

On 6 Apr 2009, at 23:14 , björn wrote:

>> thanks for this patch. MacVim feels much snappier now. There are some
>> artifacts (like empty rectangles at the beginning of the line), but
>> that's what you said is going to happen :)
>
> I've pushed an update to feat/core-text branch which hopefully takes
> care of the most obnoxious drawing artifacts. If anybody tries it out
> be sure to let me know if things have improved and what problems are
> still there.
>

Hi Bjorn,

I'm not seeing any artifacts in the text area. I'm seeing something in
the status line, though. I've attached a screen-shot. You'll notice a
couple of pixels at the very beginning of the status line. Also, these
is that dot before core/ in the file name. I didn't get the screen
shot when I was editing another file ('click/elements'). Then I had
'ilick/elements' printed in the status line.

[björn]

2009/4/7 Nikola Knežević:

>
> I'm not seeing any artifacts in the text area. I'm seeing something in
> the status line, though. I've attached a screen-shot. You'll notice a
> couple of pixels at the very beginning of the status line. Also, these
> is that dot before core/ in the file name. I didn't get the screen
> shot when I was editing another file ('click/elements'). Then I had
> 'ilick/elements' printed in the status line.

I noticed too that there are strange drawing issues when the left
scrollbar is shown -- it seems to be the same problem you are seeing.
I'll have a look at it.

Thanks for the feedback,
Björn