Tiger rendering problems

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Tiger rendering problems

Kelly Norton
Hi Folks,

I'm looking for any information or references to work around a  
strange issue that has popped up in vim 6.3 under Tiger. For  
reference, I'm using the binary from macvim.org for Tiger (and the  
default guifont). After anywhere from 15-30 minutes of working, a  
portion of one of my buffers suddenly gets an additional offset of  
about 2 characters. Usually, things continue to deteriorate from here  
and :redraw doesn't seem to help. I have posted a screenshot here:
http://web.kellegous.com/tmp/vim-rendering-glitch.png

Any help is appreciated. thanks.
/kel


Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Jussi Hagman
On 30.5.2005, at 3:10, Kelly Norton wrote:

> Hi Folks,
>
> After anywhere from 15-30 minutes of working, a portion of one of  
> my buffers suddenly gets an additional offset of about 2 characters.

This is something I have not seen myself, I don't use vim in a  
similar way either, I usually have just one window or window splitted  
just horizontally.

I'm sorry not to be able to help with this problem. I'll shamelessly  
use this opportunity to talk a bit about my own agenda, making gvim  
better on OS X, which I see as the top priority, I'm not sure if this  
view is widely shared as many seem to use vim in the terminal too.  
Hopefully this bug will be squashed at the same time the rendering is  
reworked.

There are some other rendering bugs with Tiger that I've seen myself  
(I've reported those to macvim.org) or have heard from friends. I've  
heard that on a G3 the rendering is _very_ slow under Tiger. I've  
noticed some slowness too on my G4 (especially with vim7, but it's  
not totally OK with vim6 either).

I'd like to hear if someone is working on those bugs if I don't hear  
anything I'm probably going to refactor the mac code to OS X and  
Classic portions to clear things up and try to fix the speed problems  
under Tiger. This may or may not mean going away from QuickDraw.

A forum for the development would be very nice. macvim.org is ok for  
users, but mac-oriented vim developers seem not to talk to each other  
(or maybe I've not found the place). What would be needed is a bug  
database, list of wanted features, features that are under work and  
some kind of a roadmap to plan the development.

I'd like to hear from the people that develop mac port of vim or just  
use gvim. What features do you want, what are the biggest bugs at the  
moment? What is the direction gvim should be taken? What APIs should  
be used? Are all features of current gvim still needed (like Code  
Warrior support).

If you have opinions on one of more of the questions above please  
mail me.

Greetings,
Jussi

P.S. I crossposted this also to vim-dev, sorry for any inconvenience.

--
Jussi Hagman, [hidden email], iChat/AIM: jussihagman, ICQ: 54004113
Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170

Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Bram Moolenaar

Jussi Hagman wrote:

> I'm sorry not to be able to help with this problem. I'll shamelessly  
> use this opportunity to talk a bit about my own agenda, making gvim  
> better on OS X, which I see as the top priority, I'm not sure if this  
> view is widely shared as many seem to use vim in the terminal too.  
> Hopefully this bug will be squashed at the same time the rendering is  
> reworked.

Making Vim work better on Mac OS X is often asked for.  Unfortunately,
there appear to be few people that know how to do GUI programming for
that platform.  I hardly know anything about it myself (I donn't have
time to learn a dozen different GUI libraries...).

> A forum for the development would be very nice. macvim.org is ok for  
> users, but mac-oriented vim developers seem not to talk to each other  
> (or maybe I've not found the place). What would be needed is a bug  
> database, list of wanted features, features that are under work and  
> some kind of a roadmap to plan the development.

The mac-vim list is low on trafic, I don't see a reason to split it up.

--
hundred-and-one symptoms of being an internet addict:
2. You kiss your girlfriend's home page.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Matthew Gilbert
In reply to this post by Kelly Norton
Hi Jussi,

I'm also experiencing scrolling slowness on Tiger. I've tried vim7  
from CVS, and 6.3 from macvim as well as compiling my own. vim7 is  
definitely better, but after some random amount of time scrolling  
slows way down. I have a dual 2GHz 1.5GB of RAM, so there should be  
plenty of processing power. When it slows down I've opened shark to  
get a trace (I can provide these if they're helpful). In every case  
the call tree looks something like the trace below (call hierarchy is  
not obvious in plain text) , usually spending most of the time in  
aa_render_shape (I do *not* have antialiasing enabled, I've turned it  
off through setting the AppleAntiAliasingThreshold setting as well as  
turning it off in Vim).

Anyway, I'm very interested in helping provide vim7 based on a more  
modern GUI library. I notice that wxWidgets is installed by default  
on Tiger. I'm more inclined to target wxWidgets than the Carbon  
library just because wxWidgets is applicable to other platforms. But,  
I'm interested in helping with whatever ends up being the most  
appropriate. Downside is that while I'm experienced in C, I haven't  
hacked on Vim or Carbon or much on wxWidgets (but I learn quickly).

This issue is driving me nuts, I'm starting to look into it myself,  
but if you have a head start and are interested in collaborating, I'm  
ready to work! Thanks _matt


     17.4%    17.4%    CoreGraphics    aa_render_shape
     0.0%    17.4%    libRIP.A.dylib    ripr_Coverage
     0.0%    17.4%    libRIP.A.dylib    ripc_GetClipState
     0.0%    17.4%    libRIP.A.dylib    ripc_GetRenderingState
     0.0%    14.0%    libRIP.A.dylib    ripc_DrawGlyphs
     0.0%    14.0%    CoreGraphics    CGContextDelegateDrawGlyphs
     0.0%    14.0%    CoreGraphics    drawGlyphs
     0.0%    14.0%    CoreGraphics    CGContextShowGlyphsWithAdvances
     0.0%    14.0%    QD    RenderGlyphRecordArrayWithCG
     0.0%    14.0%    QD    ATSUDrawGlyphsWithPortContext
(ATSGlyphVector*, unsigned long, unsigned long, FixedPoint*)
     0.0%    14.0%    QD    ATSUDrawGlyphs(ATSGlyphVector*, unsigned  
long, unsigned long, FixedPoint*, CGContext*)
     0.0%    14.0%    QD    TTextLineLayout::DrawText(unsigned long,  
unsigned long, long, long)
     0.0%    14.0%    QD    ATSUDrawText
     0.0%    14.0%    Vim    gui_mch_draw_string
     0.0%    14.0%    Vim    gui_outstr_nowrap
     0.0%    12.0%    Vim    gui_write
     0.0%    1.0%    Vim    gui_screenchar
     0.0%    1.0%    Vim    gui_redraw_block
     0.0%    1.7%    libRIP.A.dylib    ripc_DrawImage
     0.0%    1.7%    CoreGraphics    CGContextDelegateDrawImage
     0.0%    1.7%    libRIP.A.dylib    ripc_DrawRects
     0.0%    1.7%    CoreGraphics    __CGContextDrawRects
     0.0%    1.7%    CoreGraphics    CGContextFillRects
     0.0%    1.7%    CoreGraphics    CGContextFillRect
     0.0%    1.7%    HIToolbox    TilePixMapListCG
     0.0%    1.7%    HIToolbox    _ThemeImageTile
     0.0%    1.7%    HIToolbox    _ThemeImageDrawMultiple
     0.0%    1.7%    HIToolbox    _ThemeImageDraw3Piece
     0.0%    1.7%    HIToolbox    _HIThemeDrawScrollBar
(HIThemeTrackDrawInfo const*, CGRect const*, CGContext*)
     0.0%    1.7%    HIToolbox    _HIThemeDrawTrackInternal
(HIThemeTrackDrawInfo const*, CGRect const*, ThemeEraseXUPP*,  
unsigned long, CGContext*, unsigned long)
     0.0%    1.7%    HIToolbox    HIScrollBar::DrawSelf(short,  
__HIShape const*, CGContext*)
     0.0%    1.7%    HIToolbox    HIView::DrawCacheOrSelf(short,  
__HIShape const*, CGContext*)
     0.0%    1.7%    HIToolbox    HIView::SendDraw(short,  
OpaqueGrafPtr*, __HIShape const*, CGContext*)
     0.0%    1.7%    HIToolbox    HIView::RecursiveDrawNonComposited
(short, OpaqueGrafPtr*, OpaqueRgnHandle*, unsigned char, unsigned  
char, unsigned char)
     0.0%    1.7%    HIToolbox    HIView::DrawNonComposited(short,  
OpaqueGrafPtr*, OpaqueRgnHandle*, unsigned long)
     0.0%    1.7%    HIToolbox    HIView::EventHandler
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
     0.0%    1.7%    HIToolbox    DispatchEventToHandlers
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)
     0.0%    1.7%    HIToolbox    SendEventToEventTargetInternal
(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)
     0.0%    1.7%    HIToolbox    SendEventToEventTargetWithOptions
     0.0%    1.7%    HIToolbox    SendControlDefValueFieldChanged
(HIView*)
     0.0%    1.7%    HIToolbox    HIView::DoControlValueUpdate(bool)
     0.0%    1.7%    HIToolbox    SetControl32BitValue
     0.0%    1.7%    Vim    gui_update_scrollbars
     0.0%    1.7%    Vim    main_loop
     0.0%    1.7%    Vim    main



> On 31.5.2005, at 15:51, Bram Moolenaar wrote:
>
>
>>
>> Making Vim work better on Mac OS X is often asked for.
>>
>
> Do you have a list of specific things people have asked for (apart  
> from todo.txt)?
>
>
>> Unfortunately, there appear to be few people that know how to do  
>> GUI programming for that platform.
>>
>
> That's true. I'm no expert on that either but I'll try to learn  
> enough Carbon -API to make the performance fixes for my friend  
> who's using G3 and OS X 10.4.
>
> If I don't get any information otherwise I'm probably going to  
> delete quite much code for clarity, at least codewarrior and pre-OS  
> X support. This may turn the changes not compatible with vim goals  
> and thus not good for inclusion in the mainline.
>
> I'm starting the work tomorrow, I don't know whether I can make it  
> or how long it will take...
>
>
>> The mac-vim list is low on trafic, I don't see a reason to split  
>> it up.
>>
>
> Mac-vim list is very very low on traffic. I'd like to see a proper  
> bug database online, maybe on macvim.org. It could help  
> development, but given the state of things I'm not too hopeful.
>
> Greetings,
> Jussi
>
Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Jussi Hagman

On 31.5.2005, at 19:50, Matthew Gilbert wrote:
> I'm also experiencing scrolling slowness on Tiger. I've tried vim7  
> from CVS, and 6.3 from macvim as well as compiling my own. vim7 is  
> definitely better, but after some random amount of time scrolling  
> slows way down.

Interesting, on my G4 vim7 is much slower I don't know about G3. Some  
other things, like syntax colouring and vim settings can make the  
difference.

> I have a dual 2GHz 1.5GB of RAM, so there should be plenty of  
> processing power.

One would hope that's enough for editing text :)

> When it slows down I've opened shark to get a trace (I can provide  
> these if they're helpful).

I did some profiling too yesterday and I've got some profiles from  
friends. But sure additional shark-files can help. I'd like to  
receive them by mail or preferably download them from your website or  
similar place if that is possible.

> Anyway, I'm very interested in helping provide vim7 based on a more  
> modern GUI library. I notice that wxWidgets is installed by default  
> on Tiger. I'm more inclined to target wxWidgets than the Carbon  
> library just because wxWidgets is applicable to other platforms.

I'm very glad to hear that. I had not noticed vxWidgets on Tiger,  
which is a good news, but still I'd prefer using a native API and  
vim6 as a starting point because it is stable and that's what users  
need. But of course I'm very open for discussion.

My plan is about following:

     1. copy gui_mac.c to gui_macosx.c
     2. make the related changes to build process
     3. clean gui_macosx.c so that it contains no legacy code (from  
OS X point of view)
     4. analyze the speed problem and fix it with QuickDraw

At this point we would have a faster vim for OS X users on Tiger. And  
we would have made it easier to make OS X specific changes without  
worrying breaking the compatibility. Optimally this would not take  
too much time either.

After making the fix my plan would continue with:

     5. ask what users want and make a plan for further development
     6. see if there still is need to move away from QuickDraw
     7. see if there is need to move away from Carbon.

> But, I'm interested in helping with whatever ends up being the most  
> appropriate. Downside is that while I'm experienced in C, I haven't  
> hacked on Vim or Carbon or much on wxWidgets (but I learn quickly).

I'm not too experienced with C. I've not hacked Vim previously and  
I'm quite unfamiliar with Carbon. The only OS X programming I've done  
has been with objC + Cocoa and various scripting languages.

In a perfect world I'd like to start from scratch but that would mean  
much more work, plenty of new bugs, and longer time to fixing the  
speed problem, which I think should be fixed ASAP.

> This issue is driving me nuts, I'm starting to look into it myself,  
> but if you have a head start and are interested in collaborating,  
> I'm ready to work! Thanks _matt

I don't think I have much of a head start and I'm very much  
interested in collaborating.

About the problem, have you tried of setting showcmd and/or  
lazyredraw off

     :set noshowcmd
     :set nolazyredraw

Those settings seem to help at least partly.

--
Jussi Hagman, [hidden email], iChat/AIM: jussihagman, ICQ: 54004113
Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170

Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Matthew Gilbert

>> Anyway, I'm very interested in helping provide vim7 based on a  
>> more modern GUI library. I notice that wxWidgets is installed by  
>> default on Tiger. I'm more inclined to target wxWidgets than the  
>> Carbon library just because wxWidgets is applicable to other  
>> platforms.
>>
>
> I'm very glad to hear that. I had not noticed vxWidgets on Tiger,  
> which is a good news, but still I'd prefer using a native API and  
> vim6 as a starting point because it is stable and that's what users  
> need. But of course I'm very open for discussion.

Sounds like a good plan to me. Being new to mac development I wasn't  
sure if QuickDraw was a legacy API. After a brief read through  
developer.apple.com I'm still not sure. It sounds like maybe drawing  
should be moved to Quartz 2d?

>
> My plan is about following:
>
>     1. copy gui_mac.c to gui_macosx.c
>     2. make the related changes to build process
>     3. clean gui_macosx.c so that it contains no legacy code (from  
> OS X point of view)
>     4. analyze the speed problem and fix it with QuickDraw
>
> At this point we would have a faster vim for OS X users on Tiger.  
> And we would have made it easier to make OS X specific changes  
> without worrying breaking the compatibility. Optimally this would  
> not take too much time either.

Sounds good, hopefully the speed problem can be fixed without  
resorting to a new API. I plan on studying API's until you have this  
finished (doesn't sound like something I can help in parallel).

>
> After making the fix my plan would continue with:
>
>     5. ask what users want and make a plan for further development
>     6. see if there still is need to move away from QuickDraw
>     7. see if there is need to move away from Carbon.

Excellent.

One last thing to figure out is how you'd like to collaborate. Do you  
want to simply send patches back and forth or use something like  
darcs? I'm open to whatever.

I look forward to hear how its going with the new build fixes. Thanks  
_matt

Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Da Woon Jung
In reply to this post by Kelly Norton
The ATSUI drawing in the current Vim 7 code is not optimized. I have
not yet included the Apple-suggested tip of making a CGContext for the
ATSUI calls. This should make a difference, as the Shark profile
suggests.

Also, I'm currently reworking os_mac_conv to streamline the text
conversion code. This should also provide some more speedup, and I'll
try to get this done within a week or two so there is a stable api to
work with.

Sorry about the holdup. I don't have a summer vacation, and my
weekends haven't always been free.

Cheers,
DW
Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Jussi Hagman
In reply to this post by Matthew Gilbert

On 1.6.2005, at 6:58, Matthew Gilbert wrote:

> Sounds like a good plan to me. Being new to mac development I  
> wasn't sure if QuickDraw was a legacy API. After a brief read  
> through developer.apple.com I'm still not sure.

Well, Apple is giving a bit of mixed signals on this one. A year ago  
in WWDC they said loud and clear that QuickDraw is going to be  
deprecated[1] in Tiger. They would be doing no new development to it  
and they would not break it. What happened when Tiger was out was  
that the deprecation was not announced widely. For example I do not  
get any warnings about that while compiling Vim but on the other hand  
in "Introduction to Quartz Programming..."[2] there is a note that QD  
is deprecated.

And apparently they did something that caused Vim to break. Not nice,  
maybe I should file a bug although they seldom help much.

> It sounds like maybe drawing should be moved to Quartz 2d?

Yes, I think so. Da Woon Jung is already doing the transition at  
least partly, in vim7 (at least the last time I checked) he used QD  
and ATSUI, which is another of the many text APIs on OS X. ATSUI is  
not going away any time soon.

> Sounds good, hopefully the speed problem can be fixed without  
> resorting to a new API.

Hopefully it is possible if not then it will take some more time.

> One last thing to figure out is how you'd like to collaborate. Do  
> you want to simply send patches back and forth or use something  
> like darcs? I'm open to whatever.

Well, sending patches is not something I'd like to do. But on the  
other hand darcs, which I've tested briefly, sounds like a very good  
idea. If you are more familiar with darcs you could contact me on or  
off the list about setting it up.

I can't share the darcs repository directly from my powerbook, but I  
guess it's possible to just rsync the repository to a website for  
sharing with others, right?

> I look forward to hear how its going with the new build fixes.  
> Thanks _matt

Probably the first point should be setting up darcs and then  
proceeding with the rest.

Below you'll find my iChat screenname which could be a way to discuss  
in a faster manner.

Greetings,
Jussi

[1] http://stream.qtv.apple.com/events/jun/wwdc_2004_qt_sotu/ 
wwdc_2004_gm_sotu_ref.mov (about 31:00 - )
[2] http://developer.apple.com/documentation/Carbon/Conceptual/ 
QuickDrawToQuartz2D/tq_intro/chapter_1_section_1.html (first page,  
btw, thanks for the link Matthew)


--
Jussi Hagman, [hidden email], iChat/AIM: jussihagman, ICQ: 54004113
Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170

Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Nicholas Cole
I'd just like to say - as a user - how much I welcome people taking an
interest in the OS X port.  I use vim on both Linux and the OS X
platforms, and the speed of rendering is certainly a problem on the
Mac.

Thank you very much those who are willing (and able) to put time and
effort into this!

Best wishes,

NC
Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Jussi Hagman

On 2.6.2005, at 17:58, Nicholas Cole wrote:

> I use vim on both Linux and the OS X platforms, and the speed of  
> rendering is certainly a problem on the Mac.

The current speed problem with Tiger seems to be because of a new  
thing called coalesced updates was introduced in Tiger. It seems to  
be a bit controversial implementation that blocks the screen  
rendering so that it can be synchronized with the beam. Another  
source of lack of speed is the fact that even when the keyboard  
repeat rate is set to fastest it is still quite slow.

The worst problems are seen when both lazyupdate and showcmd options  
are set. Unsetting one of them will help as turning the beam  
synchronization off with Quartz Debug (that is provided with  
Developer Tools). One could also try setting scrolljump setting to a  
bit bigger number.

These are not permanent solutions. We'll work for providing a better  
one when we have the time, hopefully soon.

Greetings,
Jussi

--
Jussi Hagman, [hidden email], iChat/AIM: jussihagman, ICQ: 54004113
Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170

Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Da Woon Jung
In reply to this post by Kelly Norton
I got around to testing a patch to accelerate text drawing calls, with
Beam Sync both on and off. The patch works, providing as much as 30%
speedup but if beam sync is turned on that advantage is just about
negated. A Shark session reveals that several drawing calls
(EraseRect() -> CGContextSynchronize()) are needlessly bunched
together by Tiger, preventing regular processing of other events
(WaitNextEvent).

I think this can be solved by implementing a timer during scrolling
(and don't draw between timer cycles), but it just feels like a hack.
Coders programming normal apps like text editors shouldn't have to
think like they're programming a game. I'm making several inquiries
elsewhere to see if there's anything better that could be done
(doubtful).

Has anyone on the vim-mac list been to WWDC 2005? I wish I could've been there.

Cheers,
DW
Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Matthew Gilbert
Da Woon,

Is the issue universal to any Carbon app? Or will moving to Quartz 2d  
help. I think even with the ATSUI changes you've made, there are  
still many calls to QuickDraw. Just wondering if I'm wasting my time  
slowly ramping up on replacing all the drawing with Quartz 2d. Wish I  
could have gone to WWDC 2005 too. Thanks _matt


On Jun 12, 2005, at 7:46 AM, Da Woon Jung wrote:

> I got around to testing a patch to accelerate text drawing calls, with
> Beam Sync both on and off. The patch works, providing as much as 30%
> speedup but if beam sync is turned on that advantage is just about
> negated. A Shark session reveals that several drawing calls
> (EraseRect() -> CGContextSynchronize()) are needlessly bunched
> together by Tiger, preventing regular processing of other events
> (WaitNextEvent).
>
> I think this can be solved by implementing a timer during scrolling
> (and don't draw between timer cycles), but it just feels like a hack.
> Coders programming normal apps like text editors shouldn't have to
> think like they're programming a game. I'm making several inquiries
> elsewhere to see if there's anything better that could be done
> (doubtful).
>
> Has anyone on the vim-mac list been to WWDC 2005? I wish I could've  
> been there.
>
> Cheers,
> DW
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Tiger rendering problems

Da Woon Jung
The issue seems to be related to just drawing "too fast", Carbon or
not Carbon. Some optimization seems to be possible by porting the
QuickDraw calls to Quartz, but as Jussi and I mentioned, Shark
profiling reveals that the main bottleneck seems to be in Tiger's
forced beam sync. If I understand Apple correctly, regulating drawing
via a timer during scrolling ought to improve things outright by
cooperating with Tiger's beam sync.

Cheers,
DW


2005/6/15, Matthew Gilbert wrote:

> Da Woon,
>
> Is the issue universal to any Carbon app? Or will moving to Quartz 2d
> help. I think even with the ATSUI changes you've made, there are
> still many calls to QuickDraw. Just wondering if I'm wasting my time
> slowly ramping up on replacing all the drawing with Quartz 2d. Wish I
> could have gone to WWDC 2005 too. Thanks _matt
>
>
> On Jun 12, 2005, at 7:46 AM, Da Woon Jung wrote:
>
> > I got around to testing a patch to accelerate text drawing calls, with
> > Beam Sync both on and off. The patch works, providing as much as 30%
> > speedup but if beam sync is turned on that advantage is just about
> > negated. A Shark session reveals that several drawing calls
> > (EraseRect() -> CGContextSynchronize()) are needlessly bunched
> > together by Tiger, preventing regular processing of other events
> > (WaitNextEvent).
> >
> > I think this can be solved by implementing a timer during scrolling
> > (and don't draw between timer cycles), but it just feels like a hack.
> > Coders programming normal apps like text editors shouldn't have to
> > think like they're programming a game. I'm making several inquiries
> > elsewhere to see if there's anything better that could be done
> > (doubtful).
> >
> > Has anyone on the vim-mac list been to WWDC 2005? I wish I could've
> > been there.
> >
> > Cheers,
> > DW