Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 2/csmp-v2-013.txt

Text File | 1994-12-08 | 39.4 KB | 1,047 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 16 Feb 93       Volume 2 : Issue 13

Today's Topics:

    Think C Debugger Voracity
    TCL, MultiFinder, and Progress Dialogs
    Completion proc stuff
    QuickDraw: Why Can't it Mirror Right?
    My MyDoubleBackProc() is too slow!!



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you can
post articles to any newsgroup by mailing your article to
    [e-mail]
So, to post an article to comp.sys.mac.programmer, mail your article to
    [e-mail]
Note the '-' instead of '.' in the newsgroup name.  Be sure to ask that
replies be emailed to you instead of posted to the group, and give your
email address.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Art Urban)
Subject: Think C Debugger Voracity
Date: 12 Jan 93 23:11:56 GMT
Organization: Forecast Systems Lab, NOAA, Boulder CO, USA

In a sentence:

How much bloody memory does the voracious debugger need! :-)

I'm currently up to 2Meg, and the dang thing *still* exceeds it. I did
notice that after each Step command I issue, the Debugger consumes 50k+(!)
of its own heap. Everything its consuming is "unlocked" according to
Swatch, but apparently it can't purge anything.

So what's a programmer to do?

- --
Art Urban                             [e-mail]
===============================================================================
 "Look, he's being attacked by creamy nugget centers."              -Joel
===============================================================================

+++++++++++++++++++++++++++

From: [e-mail] (CAMPBELL, FRED LELAND)
Date: 13 Jan 93 05:38:00 GMT
Organization: Texas A&M University, Academic Computing Services

In article <[e-mail]>, [e-mail] (Art Urban) writes...
>I'm currently up to 2Meg, and the dang thing *still* exceeds it. I did
>notice that after each Step command I issue, the Debugger consumes 50k+(!)
>of its own heap. Everything its consuming is "unlocked" according to
>Swatch, but apparently it can't purge anything.
>
>So what's a programmer to do?

Are you using Desktop Textures or something like it to give you those really
neat desktop patterns? I had a similar problem recently and remembered
reading somewhere (here or think-c?) that when the debuggers steps through
code it copies something to do with the extended desktop pattern and this eats
up memory like crazy. I stopped using Desktop Textures and my problem went
away, your mileage may vary. (Note, I only had the problem when I was stepping
through code). Of course, this is just a guess.
Trey.

+++++++++++++++++++++++++++

From: [e-mail] (Humayun Lari)
Date: 13 Jan 1993 18:32:08 -0500
Organization: The University of North Carolina at Chapel Hill

In article <[e-mail]> [e-mail] (Art Urban) writes:
>How much bloody memory does the voracious debugger need! :-)
>
>I'm currently up to 2Meg, and the dang thing *still* exceeds it. I did
>notice that after each Step command I issue, the Debugger consumes 50k+(!)
>of its own heap. Everything its consuming is "unlocked" according to
>Swatch, but apparently it can't purge anything.

If you're using a large color pixel pattern on your desktop, the current
THINK C debugger has a bug that causes it to make a copy of the pattern every
time you step. This can use up a lot of memory. (Note that I could be wrong
about some detail or other, since this is off the top of my head.)

If not, I'm stumped.

Humayun Lari
([e-mail])


---------------------------

From: [e-mail] (Roy Richter PH/32)
Subject: TCL, MultiFinder, and Progress Dialogs
Date: 11 Jan 93 18:30:40 GMT
Organization: GM Research and Environmental Staff

I want to have a progress dialog up for an operation that takes
over a minute, so I've got the usual text string, and a horizontal
bar that fills up as the operation proceeds.  It would be nice to
also:

(1) let the Multifinder take time slices to update other programs,
    I assume that WaitNextEvent will do it;
(2) Have a "Cancel" button the user can push to cancel the
    operation.  This has me stuck.

I use the Class Library to manage the dialogs.  That way, I just
GetGoodClicks and so on.  In this case, I'm not passing control up the
line to let the DeskTop get the click and dispatch it.  I wouldn't want
to break up my operation into a bunch of Tasks, that would be
hard--since I'm updating the progress dialog in a callback.  I'd prefer
the MultiFinder timeout and clicks be self-contained in the callback.
That was I can use the callback in many places, as needed.  Otherwise
I'd need to restucture the code into a Task everytime I thought a
time-slice was needed.

Any hints?

- --
Roy Richter                  Internet: [e-mail]
Physics Dept, GM Research    UUCP:     rphroy!rrichter

+++++++++++++++++++++++++++

From: [e-mail] (Brian Stern; COMB)
Date: 11 Jan 93 21:16:00 GMT
Organization: University of Maryland, Center of Marine Biotechnology

In article <[e-mail]>, [e-mail] (Roy Richter PH/32) writes...
>I want to have a progress dialog up for an operation that takes
>over a minute, so I've got the usual text string, and a horizontal
>bar that fills up as the operation proceeds.  It would be nice to
>also:
>
>(1) let the Multifinder take time slices to update other programs,
>    I assume that WaitNextEvent will do it;
>(2) Have a "Cancel" button the user can push to cancel the
>    operation.  This has me stuck.
>
Call WNE with a mDownMask. If it returns true then call FindControl to get
the control handle (pass it theEvent.where as the point) and then
TrackControl. If TrackControl tells you that the mouseup occurred in
your cancel button then go ahead and cancel the operation. Note that Apple
now recommends a distinction between a 'Cancel' button and a 'Stop' button
where the first results in a complete return to the conditions before the
operation was started and the latter merely interuppts the operation. So if
the operation were copying files 'cancel' would delete any files that had
been copied up to the point when the cancel button was hit and 'Stop' would
leave any files which had already been copied but wouldn't copy any more.

Brian Stern
[e-mail]

+++++++++++++++++++++++++++

Date: 11 Jan 93 21:56:03 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <[e-mail]> [e-mail] (Brian Stern; COMB) writes:

>>I want to have a progress dialog up for an operation that takes
>>over a minute, so I've got the usual text string, and a horizontal

>>(1) let the Multifinder take time slices to update other programs,
>>    I assume that WaitNextEvent will do it;
>>(2) Have a "Cancel" button the user can push to cancel the
>>    operation.  This has me stuck.

>Call WNE with a mDownMask. If it returns true then call FindControl to get
>the control handle (pass it theEvent.where as the point) and then
>TrackControl. If TrackControl tells you that the mouseup occurred in

Actually, this is a bad thing to do to a TCL app; for instance
AppleEvents would be lost because they are ALWAYS delivered
regardless of event mask.

Instead, I usually put up a movable, modal dialog with the bar
etc, and when I need to give idle time, I do:

    gSleepTime = 0 ;
    gApplication -> Process1Event ( ) ;

If you can set up an Idle chore to do the idling, you could
even have your dialog be the supervisor of the chore and have
BeginDialog and EndDialog handle dialog ending.

So what does this do? Well, you can't call DoModalDialog if you
cannot push the thing you're doing into a chore; you'll have
to mimic the behaviour in your idle call. What remains is to
handle DoCommand ( cmdCancel ) by overriding it in the
CDLOGDirector.

Hope this helps,

                            / h+
- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
   This signature is kept shorter than 4 lines in the interests of UseNet
   S/N ratio.

+++++++++++++++++++++++++++

From: [e-mail] (Rick Eames)
Date: 12 Jan 93 17:47:21 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Jon
Wtte) wrote:

> Actually, this is a bad thing to do to a TCL app; for instance
> AppleEvents would be lost because they are ALWAYS delivered
> regardless of event mask.
>
> Instead, I usually put up a movable, modal dialog with the bar
> etc, and when I need to give idle time, I do:
>
>     gSleepTime = 0 ;
>     gApplication -> Process1Event ( ) ;
>
> If you can set up an Idle chore to do the idling, you could
> even have your dialog be the supervisor of the chore and have
> BeginDialog and EndDialog handle dialog ending.
>
> So what does this do? Well, you can't call DoModalDialog if you
> cannot push the thing you're doing into a chore; you'll have
> to mimic the behaviour in your idle call. What remains is to
> handle DoCommand ( cmdCancel ) by overriding it in the
> CDLOGDirector.
>

The problem with this method is that your damned cursor ends up resetting
to a pointer each time you Process1Event() so you have to override that too
to ensure that your nice spinning cursor works.

############################################################################
Rick Eames                         Internet:      [e-mail]
Apple Computer, Inc.               CompuServe:    76666,2114
My Opionions are my own.           AmericaOnline: EamesR
"The Lord prefers common-looking people. That is why he makes so many of
them."  - Lincoln

"But you know what?  There's another point that I'd like to make: it's very
possible that Adolf Hitler kept a very nice check book.  You know?  I mean,
and that's fine."  -- Barbara Boxer, Bill Press Show, KFI, 10/24/92
############################################################################

+++++++++++++++++++++++++++

From: [e-mail] (Joshua Rabinowitz-Summer-91)
Date: 12 Jan 93 20:21:47 GMT
Organization: NASA/ARC Information Sciences Division

In article <[e-mail]> [e-mail] (Roy Richter PH/32) writes:
>I want to have a progress dialog up for an operation that takes
>over a minute, so I've got the usual text string, and a horizontal
>bar that fills up as the operation proceeds.  It would be nice to
>also:
>
>(1) let the Multifinder take time slices to update other programs,
>    I assume that WaitNextEvent will do it;
>(2) Have a "Cancel" button the user can push to cancel the
>    operation.  This has me stuck.
>
>I use the Class Library to manage the dialogs.  That way, I just
>GetGoodClicks and so on.  In this case, I'm not passing control up the
>line to let the DeskTop get the click and dispatch it.  I wouldn't want
>to break up my operation into a bunch of Tasks, that would be
>hard--since I'm updating the progress dialog in a callback.  I'd prefer
>the MultiFinder timeout and clicks be self-contained in the callback.
>That was I can use the callback in many places, as needed.  Otherwise
>I'd need to restucture the code into a Task everytime I thought a
>time-slice was needed.
>
>Any hints?
>
>--
>Roy Richter                  Internet: [e-mail]
>Physics Dept, GM Research    UUCP:     rphroy!rrichter


One really sloppy method that I cannot see anyone recommending
(discussion ?) is to call WaitNextEvent from within a loop,
masking out all events so they remain in the queue until
the appropriate time.
But I don't think this is good.

An easier (but not great) way to handle cancels
is to use GetKeys and check for command-period.

I have code to do this if anyone wants.  The problem is that it will not
work properly with some alternate keyboard systems (?) and
inits (?)  (I think.  Check the Develop article where someone
          talks about repetitive strain injury and has to
          'type' with her feet.)





- --
- ----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
[e-mail]
"Me lost my cookie at the disco." -- Cookie Monster

+++++++++++++++++++++++++++

Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 14 Jan 1993 17:33:19 GMT

In <[e-mail]> [e-mail] (Rick Eames) writes:

>The problem with this method is that your damned cursor ends up resetting
>to a pointer each time you Process1Event() so you have to override that too
>to ensure that your nice spinning cursor works.

No, you can also override the cursor dispatch mechanism.
I don't remember it offhand, but it's probably a much better
place to do it.

{20-line .sig deleted}

Using 20 lines of .sig means showing no respect for people
with 2400 baud modems.

Cheers,

                            / h+
- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

   There's no problem that can't be solved using brute-force algorithms
   and a sufficiently fast computer. Ergo, buy more hardware.    (NOT!)

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 14 Jan 1993 19:49:46 GMT

tte) writes:
>[e-mail] (Rick Eames) writes:
>
>>The problem with this method is that your damned cursor ends up resetting
>>to a pointer each time you Process1Event() so you have to override that too
>>to ensure that your nice spinning cursor works.
>
>No, you can also override the cursor dispatch mechanism.
>I don't remember it offhand, but it's probably a much better
>place to do it.

Yep, CDesktop::DispatchCursor() is the method to override.  See my
CAnimCursor, ftp'able from ftp.brown.edu or sumex-aim.stanford.edu,
for details.  Roughly, my CAcurDesktop::DispatchCursor() method
looks like this:

if (the cursor is spinning and it wants to keep spinning smoothly) {
    if (gInBackground || !CrsrVis) {
    return;
    }
    CView::cCurrHelpView = NULL;
    gAnimCursor->animateCursor();    // This spins the cursor, if it's
                    // appropriate to do so
} else {
    inherited::DispatchCursor();
}


Hmmm, another article looking for a home in comp.sys.mac.oop.tcl...
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "A degree in Computer Science from Berkeley didn't much qualify me to uphold
  the banner of Chaos against the forces of Order."              - R. Zelazny

---------------------------

From: [e-mail] (David Peterson)
Subject: Completion proc stuff
Date: 12 Jan 93 09:19:42 GMT
Organization: University of Southern California, Los Angeles, CA



I wrote a network copy program and thought I'd be clever and chain completion
procs together to handle the I/O in order to keep the process invisible to the
rest of the Mac. ie: receive completion does a write, write completion does a
recieve, and the Mac still responds to me.

Well, it works great except that it hangs the machine for the duration of the
copy. The mouse still moves around the screen and events still get posted, but
they don't get processed until the copy is finished.

What gives? Do I have to suspend my completion proc chain momentarily to give
the system time to do other stuff? I thought that by doing things asyncronously
the I/O stuff would go on in the background leaving the machine free to handle
user events.

By chaining things together like that did I just create one monster interupt
routine, or does the rest of the system get time when I go through PBControl?

Did I screw up my code or my thinking? (or both)

If it matters, I'm going from MacTCP to the File Manager under 7.1.

- -dave.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 13 Jan 93 21:42:05 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail] (David
Peterson) wrote:
>
>
>
> I wrote a network copy program and thought I'd be clever and chain completion
> procs together to handle the I/O in order to keep the process invisible to the
> rest of the Mac. ie: receive completion does a write, write completion does a
> recieve, and the Mac still responds to me.
>
> Well, it works great except that it hangs the machine for the duration of the
> copy. The mouse still moves around the screen and events still get posted, but
> they don't get processed until the copy is finished.
>
> What gives? Do I have to suspend my completion proc chain momentarily to give
> the system time to do other stuff? I thought that by doing things asyncronously
> the I/O stuff would go on in the background leaving the machine free to handle
> user events.
>
> By chaining things together like that did I just create one monster interupt
> routine, or does the rest of the system get time when I go through PBControl?
>
> Did I screw up my code or my thinking? (or both)
>
> If it matters, I'm going from MacTCP to the File Manager under 7.1.
>
> -dave.

I think your problem is basically that the Mac SCSI manager is currently
synchronous; if you do a write to the disk, that call does not return
until all the data has been written.  Thus, what I think is happening
is:

1) You do an async read from TCP
2) The async call to TCP returns
3) Eventually, the TCP read completes
4) Your TCP completion routine is called
5) You do an async write to the SCSI disk
6) All the data is written
7) Your completion routine is called
8) The async call to the disk driver returns

There are two important facts to be gleaned: 1) Because the disk driver
is synchronous, your application doesn't execute while you're writing
to the disk.  If your TCP data arrives quickly enough, you could actually
keep the data arriving faster than it's being written out; this would
cause your CPU to spend all of its time transferring data, with no time
to service your application.

2) Because the disk driver is synchronous, it does all of its data
transfer when you make the Read() or Write() call, regardless of
whether it is synchronous or asynchronous.  This means your completion
routine is called before the asynchrounous call returns.  If it in
turn make a new asynchronous call before finishing, that call's
completion routine will be called before the Device Manager call
returns; this could lead to reentrancy or stack usage problems if
you're not extremely careful.  If you have this problem, the best way
to deal with this is to defer posting new asynchronous requests until
the stack has a chance to unwind itself, perhaps by using the Time
Manager to post it later.  I don't think your case will have this
problem because one half of your transfer is TCP-based, which is
fully asynchronous, so it will give the routines some time to unwind.
However, if your TCP data arrives fast enough so that your write can
always be satisfied entirely out of the buffer, then your request may
be completed immediately, giving you the same effect as a synchronous
write.

Tim Dierks
MacDTS, but I speak for myself

+++++++++++++++++++++++++++

Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 14 Jan 1993 17:29:21 GMT

In <[e-mail]> [e-mail] (David Peterson) writes:


>What gives? Do I have to suspend my completion proc chain momentarily to give
>the system time to do other stuff? I thought that by doing things asyncronously
>the I/O stuff would go on in the background leaving the machine free to handle
>user events.

Well, it's like this:

The Mac SCSI driver doesn't support async calls.

If you do overlapping I/O, floppies and networks will give
you reads while you write to disk, though.

- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

   There's no problem that can't be solved using brute-force algorithms
   and a sufficiently fast computer. Ergo, buy more hardware.    (NOT!)

---------------------------

From: [e-mail] (Art Urban)
Subject: QuickDraw: Why Can't it Mirror Right?
Date: 5 Jan 93 19:19:18 GMT
Organization: Forecast Systems Lab, NOAA, Boulder CO, USA

There is something wrong with either QuickDraw or me... :-)

If I draw a line from 0,0 down and to the left, why won't QuickDraw mirror
the line when I draw it down and to the *right*?

I've examined the resulting bitmaps by taking screenshots and looking at
them in Canvas. The choices that QuickDraw makes for pixel placement are
different, yet the lines begin and end in mirrored coordinates. No matter
what I do, I cannot coerce QuickDraw to create a mirrored (pixel for pixel)
line angle. I need this for a bisymetrical region I'm making, so I can't
just flip around some CopyBits operation (I presume).

I realize that mathematically my region will be defined correctly, but I
want it to be drawn with some semblance of accuracy on the screen when I
call FrameRgn(). If QuickDraw can do it correctly to the left, why can't it
do it correctly to the right? (or vise-versa :-) )

- --
Art Urban                             [e-mail]
===============================================================================
 "Look, he's being attacked by creamy nugget centers."              -Joel
===============================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 5 Jan 93 22:31:22 GMT
Organization: Kalamazoo College

[e-mail] (Art Urban) writes:
>There is something wrong with either QuickDraw or me... :-)
>
>If I draw a line from 0,0 down and to the left, why won't QuickDraw mirror
>the line when I draw it down and to the *right*?

'coz it doesn't use a very good algorithm.  QD always draws lines from
top to bottom, but instead of splitting the horizontal error equally
along the line, it biases it.  Are you getting a bias toward the top
when you draw left and a bias toward the bottom when you draw right?
(Just a guess.)

>No matter
>what I do, I cannot coerce QuickDraw to create a mirrored (pixel for pixel)
>line angle.

Nope.  You can't.  Even if you could, I heard someone making noises
about 7.1 drawing lines differently than all previous systems.  If true,
you probably don't want to use lines to make regions where every pixel
is important.

>I need this for a bisymetrical region I'm making, so I can't
>just flip around some CopyBits operation (I presume).

Well, when I needed a small hexagon region a few weeks ago, I ended up
framing all the individual rectangles, top to bottom.  It's not pretty,
but I only had to make it once, and the resulting region is exactly the
same as if I did it with LineTo()s.  Except that it'll still be the same
even when System 12 is released and LineTo(), instead of drawing
straight lines, uses cubic splines which for technical reasons will only
be able to _approximate_ straightness...

If your region is too big to fabricate with rectangles, I don't know
what to tell you.  Anyone have any bright ideas?
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "Estimated number of DOS viruses in existence today:  1,500
  Number of Macintosh-based viruses:  Less than 40
  New DOS viruses discovered in summer '92:  More than 100"   - ComputerWorld

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 5 Jan 93 21:59:48 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Art Urban) writes:
>I realize that mathematically my region will be defined correctly, but I
>want it to be drawn with some semblance of accuracy on the screen when I
>call FrameRgn(). If QuickDraw can do it correctly to the left, why can't it
>do it correctly to the right? (or vise-versa :-) )

Inside Macintosh often gives the impression that regions are infinitely
accurate when it says that regions are a mathematical representation of
areas. In fact, a region is really just a packed bitmap. The packing
method happens to be patented by Apple, but it's not fancy or anything.

So, if QD draws a line "incorrectly", then the pixels in the region will
also be incorrect in the same way.

I suggest that you try using a bitmap mask that you draw with polygons.
It may be faster than using regions, although this depends on the situation.

- --
  Juri Munkki                           Windsurf: fast sailing
 [e-mail]                          Macintosh: fast software

+++++++++++++++++++++++++++

From: [e-mail] (Robert Mah)
Organization: PANIX Public Access Unix, NYC
Date: Wed, 6 Jan 1993 07:28:46 GMT

In <[e-mail]> [e-mail] (Art Urban) writes:

>If I draw a line from 0,0 down and to the left, why won't QuickDraw mirror
>the line when I draw it down and to the *right*?

The reason is that the coordinates you are passing to QuickDraw routines are
NOT pixel locations.  They are the locations BETWEEN pixels.

Thus, if you draw a line from (0,0) to (4,0), with a pensize of (1,1), it
will be 5 pixels long.  But if you draw (0,0) to (-4,0) with a pensize of
(1,1), the line will be still be 5 pixels long, but have a RIGHT location
at coordinate 1.  The key is that the "pen" hangs down and to the right of
the "pen location".  And LINE drawing takes place using the pen.

You should re-read the beginning of the Quickdraw chapter in IM-I for a
much clearer description of the graphics model used within QD.

Good luck,
Rob
- --
[--------------------------------------------------]
[  Robert S. Mah   |  "Every day an adventure,     ]
[  [e-mail]  |   every moment a challenge."  ]
[--------------------------------------------------]

+++++++++++++++++++++++++++

Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Wed, 6 Jan 1993 14:34:10 GMT

In <[e-mail]> [e-mail] (Art Urban) writes:

>If I draw a line from 0,0 down and to the left, why won't QuickDraw mirror
>the line when I draw it down and to the *right*?

Maybe because the pen has a physical size, and its centre is
not placed on the grid intersection? Try setting the pen size
(1,0) or (0,1) and see what happens.

Cheers,

                        / h+
- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

   Cookie Jar: Vanilla Yoghurt with Crushed Oreos.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 6 Jan 93 17:23:30 GMT
Organization: Kalamazoo College

[e-mail] (Robert Mah) writes:
>[e-mail] (Art Urban) writes:
>
>>If I draw a line from 0,0 down and to the left, why won't QuickDraw mirror
>>the line when I draw it down and to the *right*?
>
>The reason is that the coordinates you are passing to QuickDraw routines are
>NOT pixel locations.  They are the locations BETWEEN pixels.
>
>Thus, if you draw a line from (0,0) to (4,0), with a pensize of (1,1), it
>will be 5 pixels long.  But if you draw (0,0) to (-4,0) with a pensize of
>(1,1), the line will be still be 5 pixels long, but have a RIGHT location
>at coordinate 1.  The key is that the "pen" hangs down and to the right of
>the "pen location".  And LINE drawing takes place using the pen.
>
>You should re-read the beginning of the Quickdraw chapter in IM-I for a
>much clearer description of the graphics model used within QD.

And Jon Waette comments:
>Maybe because the pen has a physical size, and its centre is
>not placed on the grid intersection? Try setting the pen size
>(1,0) or (0,1) and see what happens.

If I read Art correctly, he's not concerned about the pixels themselves;
he's concerned about the region formed by his LineTo()s.  And, as IM
I-181 says, "Only the line endpoints and shape boundaries affect the
region definition;  the pen mode, pattern and size do not affect it."

The fact that the pen hangs down and right is irrelevant to region-
building.  However, the way that the pixels are drawn will tell you how
the region's boundaries are drawn.  Art is concerned, not that the
pixels are drawn funny, but that his region will be built funny.  That's
a problem with the way LineTo() chooses where to go, and that's not
something you can cure by messing with the pen.  You _might_ be able to
patch things up, to some degree, by picking your endpoints in an attempt
to outsmart the algorithm, but that has nothing to do with the pen
hanging one way or t'other.

Of course, maybe I read Art's question incorrectly...?  Art, I would
advise testing out your region with the region itself, not by looking
at the pixels drawn by the same set of LineTo()s--the two are not the
same.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "Estimated number of DOS viruses in existence today:  1,500
  Number of Macintosh-based viruses:  Less than 40
  New DOS viruses discovered in summer '92:  More than 100"   - ComputerWorld

+++++++++++++++++++++++++++

From: [e-mail] (Bill Williams)
Organization: HoloNet National Internet Access BBS: 510-704-1058/modem
Date: Thu, 14 Jan 1993 07:44:52 GMT



IT IS TRUE that it comes as a shock to many when drawing a sweeping series of
lines rotated about a single point that the moire pattern is distressingly
non-symetric with the Macintoshes Line routine because of the way a point
is defined in Inside Mac I.

I have no argument with it. With QuickDraw GX and other non-pixellated drawing
systems it may indeed be a fine thing... but....

when I rewrote many Quickdraw routines from scratch for my own purposes
(speed for animation) I rewrote the coordinate system such that lines and
other items conformed to the center of the pixel boundaries not the
intersecting edges.

I did this because I noticed that ugly moire patterns that were not
symetrical and other such ugly things were eliminated.

Ah, peace at last.

I can understand the original authors felling of anger over his apparent
misunderstanding of why Quickdraw works the way it does, or how to play
games to get the lines to draw the way he wants (admittedly screwing up
the bounds of his regions) but there are some people who reject apple's
coordinate system altogether, like me for instance, and do not feel
ashamed to say that centers of pixels are a better place for the point for
the sake of symmetry alone.


Bill Williams


+++++++++++++++++++++++++++

Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 14 Jan 1993 18:26:50 GMT

In <[e-mail]> [e-mail] (Bill Williams) writes:

>the bounds of his regions) but there are some people who reject apple's
>coordinate system altogether, like me for instance, and do not feel
>ashamed to say that centers of pixels are a better place for the point for
>the sake of symmetry alone.

You want to build a fence; 100m, with fenceposts every 10
meters. Now, how many posts do you need?

:-)

- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
   The word "politics" is derived from the word "poly", meaning
   "many", and the word "ticks", meaning "blood sucking parasites".
                     -- Larry Hardiman

+++++++++++++++++++++++++++

From: [e-mail] (Herb Poppe)
Organization: Scientific Computing Division/NCAR Boulder, CO
Date: Fri, 15 Jan 1993 16:29:57 GMT

 In <[e-mail]> [e-mail] (Bill Williams)
writes:

 > the bounds of his regions) but there are some people who reject apple's
 > coordinate system altogether, like me for instance, and do not feel
 > ashamed to say that centers of pixels are a better place for the point for
 > the sake of symmetry alone.

How does this help if you draw a two pixel-wide line?

Herb Poppe                 National Center for Atmospheric Research (NCAR)
[e-mail]       1850 Table Mesa Dr.
[phone]             Boulder, CO  80303

---------------------------

From: [e-mail] (Tom Erbe)
Subject: My MyDoubleBackProc() is too slow!!
Date: 14 Jan 1993 23:58:46 GMT
Organization: Mills College, Oakland CA


I am the author of a program which reads and writes many different formats
of soundfiles.  I though (naively) that I would simply add a play function.
I need to play back both 8 and 16 bit, signed and unsigned samples.  I have
most everything working, but it is just a hair too slow to eliminate
clicking. I believe that my loops to convert signed to unsigned are the
problem.  Or rather, these loops probably account for most of the
processing time and I would benefit most if they were optimized.

here is the part of my code that contains the loop (from MyDoubleBackProc()):
- ----
switch(inSI.packMode)
{
    case SF_FORMAT_LINEAR_8:
        FSRead(inSI.dFileNum, &sizeRead, charBlock);
        for(i=0; i < SIZE_BLOCK; i++)
            doubleBuffer->dbSoundData[i] = charBlock[i] + 128;
            break;
    case SF_FORMAT_LINEAR_16:
        FSRead(inSI.dFileNum, &sizeRead, shortBlock);
        etcetera.....
- ----

Is anyone well enough versed on mac and 680x0 optimization tricks to help
me with this one?  BTW, my code is in Think C 5.0 and most of it is based
on the example code on pages 22-72 to 22-77 of IM VI.

Thank you very much,

- --
tom erbe
ccm - mills college
5000 macarthur blvd.
oakland, ca 94613

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 15 Jan 93 00:48:26 GMT
Organization: Kalamazoo College

[e-mail] (Tom Erbe) writes:
>
>I have
>most everything working, but it is just a hair too slow to eliminate
>clicking. I believe that my loops to convert signed to unsigned are the
>problem.  Or rather, these loops probably account for most of the
>processing time and I would benefit most if they were optimized.

I don't know about that...I would imagine that the FSRead takes up most
of the time.

>    case SF_FORMAT_LINEAR_8:
>        FSRead(inSI.dFileNum, &sizeRead, charBlock);
>        for(i=0; i < SIZE_BLOCK; i++)
>            doubleBuffer->dbSoundData[i] = charBlock[i] + 128;
>        break;

Adding 128 to a byte and throwing away the overflow is the same thing as
inverting its hi bit, that is, EORing the byte with 0x80.  So the
fastest way to do that loop, I think, would be:

{
   register short i;
   register long scratch;
   register long *src, *dest;
   register long constHex80808080;
   src = &doubleBuffer->dbSoundData[0];
   dest = &charBlock[0];
   i = SIZE_BLOCK / 4 - 1;
   constHex80808080 = 0x80808080;
   asm {
@loopStart:
      move.l    (src)+, scratch
      eor.l     constHex80808080, scratch
      move.l    scratch, (dest)+
      dbra      i, @loopStart
   }
}

This assumes that SIZE_BLOCK is evenly divisible by four, and that it's
between 4 and 262,140 (so that i won't overflow).

I would think it would be faster to eor the constant directly into
memory, but eor doesn't seem to want to take an auto-incrementing
argument in its destination, so it would come out to three instructions
anyway.  I haven't actually counted the cycles, but I'd guess the above
solution is the fastest.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "The most dishonest, lying people I've ever met are homosexuals.  There
  probably are some honest homosexuals out there -- but so few as to be
  irrelevant."     - Clayton E. Cramer, three days after Christmas, 1992

+++++++++++++++++++++++++++

From: [e-mail] (Jim Cathey)
Date: 15 Jan 93 02:21:35 GMT
Organization: Olivetti North America, Spokane, WA

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>I would think it would be faster to eor the constant directly into
>memory, but eor doesn't seem to want to take an auto-incrementing
>argument in its destination, so it would come out to three instructions
>anyway.  I haven't actually counted the cycles, but I'd guess the above
>solution is the fastest.

It should work, my ref card shows EOR.L Dn,(An)+ as taking 20 cycles
on the 68010.


- --
+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            One Design to rule them all; one Design to find them.
            One Design to bring them all and in the darkness bind
            them.  In the land of Mediocrity where the PC's lie.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Fri, 15 Jan 1993 04:46:57 GMT

[e-mail] (Jim Cathey) writes:
>[e-mail] (Jamie R. McCarthy) writes:
>>...eor doesn't seem to want to take an auto-incrementing
>>argument in its destination...[so] I'd guess the above
>>solution is the fastest.
>
>It should work, my ref card shows EOR.L Dn,(An)+ as taking 20 cycles
>on the 68010.

You're right.  My way of testing these things is to try them in Think C
in the background.  I must have done something wrong, 'coz it works now.

Still believing that the FSRead is taking most of the time, I amend
my code to:

{
   register long *src, *dest;
   register short i;
   register long constHex80808080;
   src = &doubleBuffer->dbSoundData[0];
   dest = &charBlock[0];
   i = SIZE_BLOCK / 4 - 1;
   constHex80808080 = 0x80808080;
   asm {
@loopStart:
      move.l    (src)+, (dest)
      eor.l     constHex80808080, (dest)+
      dbra      i, @loopStart
   }
}
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "This sounds like a semantico-psychological backwardization of the
  real world image."                                   - Dave Bloom

+++++++++++++++++++++++++++

From: [e-mail] (Christer Ericson)
Date: 15 Jan 93 16:42:11 GMT
Organization: Dep. of Info.Proc, Umea Univ., Sweden

In <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>
>[...]
>
>Still believing that the FSRead is taking most of the time, I amend
>my code to:
>
>[...]
>      move.l    (src)+, (dest)
>      eor.l     constHex80808080, (dest)+
>[...]

I wouldn't do that if I were you. The first piece of code you wrote was
faster, and I really do think that it is better to have a marginally
faster code, than saving a whopping 2 bytes of code in this case.

The cycle time calculations are given below:

    MOVE.L    (A0)+,D0    ;12c    MOVE.L    (A0)+,(A1)    ;20c
    EOR.L    D1,D0        ;6c    EOR.L    D1,(A1)+    ;20c
    MOVE.L    D0,(A1)+    ;12c                -----
                -----                40c
                30c

It is almost always the case that code using more memory accesses
is slower than code using less memory accesses, just like above.


Christer Ericson --- Internet: [e-mail] --- tel: [phone]
Department of Computer Science, University of Umea, S-90187 UMEA, SWEDEN

---------------------------

End of C.S.M.P. Digest
**********************