Re: Tiger rendering problems
- 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.
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