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

Re: Tiger rendering problems

Expand Messages
  • 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 1 of 14 , Jun 1, 2005
    View Source
    • 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 2 of 14 , Jun 2, 2005
      View Source
      • 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 3 of 14 , Jun 10, 2005
        View Source
        • 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 4 of 14 , Jun 12, 2005
          View Source
          • 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 5 of 14 , Jun 14, 2005
            View Source
            • 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 6 of 14 , Jun 18, 2005
              View Source
              • 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.