Loading ...
Sorry, an error occurred while loading the content.

Tiger rendering problems

Expand Messages
  • 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
    Message 1 of 14 , May 29, 2005
    • 0 Attachment
      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
    • Jussi Hagman
      ... 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
      Message 2 of 14 , May 31, 2005
      • 0 Attachment
        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, jhagman@..., iChat/AIM: jussihagman, ICQ: 54004113
        Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170
      • Bram Moolenaar
        ... 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.
        Message 3 of 14 , May 31, 2005
        • 0 Attachment
          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 -- Bram@... -- 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 ///
        • Jussi Hagman
          ... Do you have a list of specific things people have asked for (apart from todo.txt)? ... That s true. I m no expert on that either but I ll try to learn
          Message 4 of 14 , May 31, 2005
          • 0 Attachment
            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

            --
            Jussi Hagman, jhagman@..., iChat/AIM: jussihagman, ICQ: 54004113
            Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170
          • Matthew Gilbert
            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
            Message 5 of 14 , May 31, 2005
            • 0 Attachment
              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
              >
            • Jussi Hagman
              ... 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. ... One
              Message 6 of 14 , May 31, 2005
              • 0 Attachment
                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, jhagman@..., iChat/AIM: jussihagman, ICQ: 54004113
                Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170
              • Matthew Gilbert
                ... 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
                Message 7 of 14 , May 31, 2005
                • 0 Attachment
                  >> 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
                • Da Woon Jung
                  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
                  Message 8 of 14 , Jun 1 12:41 AM
                  • 0 Attachment
                    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
                  • Jussi Hagman
                    ... 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.
                    Message 9 of 14 , Jun 1 4:18 AM
                    • 0 Attachment
                      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, jhagman@..., iChat/AIM: jussihagman, ICQ: 54004113
                      Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170
                    • 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
                      Message 10 of 14 , Jun 2 7:58 AM
                      • 0 Attachment
                        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
                      • Jussi Hagman
                        ... 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
                        Message 11 of 14 , Jun 10 7:08 AM
                        • 0 Attachment
                          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, jhagman@..., iChat/AIM: jussihagman, ICQ: 54004113
                          Studentbyn 4 D 33, 20540 Åbo, Finland +358 50 56 51 170
                        • Da Woon Jung
                          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
                          Message 12 of 14 , Jun 12 7:46 AM
                          • 0 Attachment
                            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
                          • 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
                            Message 13 of 14 , Jun 14 5:43 PM
                            • 0 Attachment
                              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
                              >
                              >
                            • 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
                              Message 14 of 14 , Jun 18 12:14 AM
                              • 0 Attachment
                                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
                              Your message has been successfully submitted and would be delivered to recipients shortly.