[futurebasic] Re: Re: [FB] Slow QuickDraw

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 1999 : Group Archive : Group : All Groups

From: BMichael@...
Date: Sun, 31 Jan 1999 15:17:29 EST
>This is interesting.  I too found the GWorld draw to be faster (by a 
>factor of
>almost 3 on my G3).  Here's a speculation:  When drawing to screen, QD surely
>has to check the current status of the clip region and vis region before
>_each_ drawing command.  But since those regions never change in a GWorld, QD
>shouldn't have to perform that check.  Maybe that's enough to accont for the
>speed difference.

Another factor that may be involved is if QD "waits" for one screen-draw 
command to complete before beginning the next. The video card itself may 
actually slow down execution in this case - for example, if the video 
buffer is full and QD must wait for the next screen refresh to flush the 
buffer.

I'd be curious to see timings on the _same_ Mac, with and without a 
high-speed video card; but then again, as the original poster said, 
adding a MacTell card did little and may even have slowed it down. But 
I'm not at all sure that DRAWPOLY is one of the commands likely to be 
"accellerated" on most QD-accel cards. COPYBITS is much more likely, for 
scrolling is the prime accelleration candidate. What we really need is a 
"known slow" video system (such as the old shared-memory approach of the 
IIsi) compared with a speedy accellerator.

Regardless, if "actually going to hardware" _does_ cause any slowdown, as 
I would expect, drawing to a GWorld will always be faster. Assuming, of 
course, that the processor speed is faster than the video hardware - 
which probably wasn't true back when Ross & Rick did their tests that 
showed no difference. (And which probably negates the value of testing on 
a IIsi.)

Bill