commons@Sunburn.Stanford.EDU (Peter Commons) (11/07/90)
Given you know whether a Mac has color Quickdraw or not, how do you determine screen depth? Thanks. -- ------------------------------ Peter Commons commons@cs.stanford.edu Computer Science Department, Stanford University
phils@chaos.cs.brandeis.edu (Phil Shapiro) (11/07/90)
In article <1990Nov6.231358.18153@Neon.Stanford.EDU> commons@Sunburn.Stanford.EDU (Peter Commons) writes:
Given you know whether a Mac has color Quickdraw or not, how do you
determine screen depth?
I use:
#define ScreenDepth(gdh) ((**((**gdh).gdPMap)).pixelSize)
#define MaxColors(gdh) (1L<<ScreenDepth(gdh))
where gdh is a GDHandle (graphic device handle).
-phil
--
Phil Shapiro Technical Support Analyst
Language Products Group Symantec Corporation
Internet: phils@chaos.cs.brandeis.educbm@well.sf.ca.us (Chris Muir) (11/08/90)
This is from a working program:
#include <Color.h>
typedef struct ScreenWorld
{
int bitDepth;
int inColor;
int hPix;
int vPix;
}ScreenWorld;
void GetScreenInfo(ScreenWorld *theScreen);
void GetScreenInfo(theScreen)
ScreenWorld *theScreen;
{
GDHandle curGD;
Rect tempRect;
curGD = GetGDevice();
tempRect = (**(**curGD).gdPMap).bounds;
theScreen->hPix = tempRect.right - tempRect.left;
theScreen->vPix = tempRect.bottom - tempRect.top;
theScreen->bitDepth = (**(**curGD).gdPMap).pixelSize;
theScreen->inColor = (BitTst( &( (**curGD).gdFlags ), 15));
}
--
__________________________________________________________________________
Chris Muir | "There is no language in our
cbm@well.sf.ca.us | lungs to tell the world just
{hplabs,pacbell,ucbvax,apple}!well!cbm | how we feel" - A. Partridgehawley@adobe.COM (Steve Hawley) (11/09/90)
In article <PHILS.90Nov7104254@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >#define ScreenDepth(gdh) ((**((**gdh).gdPMap)).pixelSize) >#define MaxColors(gdh) (1L<<ScreenDepth(gdh)) > >where gdh is a GDHandle (graphic device handle). Phil -- if your handle is not locked, isn't there a potential problem with the order of evaluation of the dereferences --especially in a context that may move memory? Steve Hawley hawley@adobe.com -- "I'm sick and tired of being told that ordinary decent people are fed up with being sick and tired. I know I'm certainly not, and I'm sick and tired of begin told that I am." -Monty Python
phils@chaos.cs.brandeis.edu (Phil Shapiro) (11/10/90)
In article <8068@adobe.UUCP> hawley@adobe.COM (Steve Hawley) writes: In article <PHILS.90Nov7104254@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >#define ScreenDepth(gdh) ((**((**gdh).gdPMap)).pixelSize) >#define MaxColors(gdh) (1L<<ScreenDepth(gdh)) > >where gdh is a GDHandle (graphic device handle). Phil -- if your handle is not locked, isn't there a potential problem with the order of evaluation of the dereferences --especially in a context that may move memory? Actually, I don't think so -- the code ScreenDepth() generates will completely evaluate to the contents of the pixelSize field without moving memory. If pixelSize were an array or struct (like bounds) then this could cause problems. My macro is a bit sloppy, though, I really should have used (**(gdh)) (not (**gdh)) in the macro body. -phil -- Phil Shapiro Technical Support Analyst Language Products Group Symantec Corporation Internet: phils@chaos.cs.brandeis.edu
oster@well.sf.ca.us (David Phillip Oster) (11/13/90)
In article <8068@adobe.UUCP> hawley@adobe.UUCP (Steve Hawley) writes: _>In article <PHILS.90Nov7104254@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: _>>#define ScreenDepth(gdh) ((**((**gdh).gdPMap)).pixelSize) _>>#define MaxColors(gdh) (1L<<ScreenDepth(gdh)) _>>where gdh is a GDHandle (graphic device handle). _>Phil -- if your handle is not locked, isn't there a potential problem with _>the order of evaluation of the dereferences --especially in a context that _>may move memory? _>Steve Hawley Steve, you should go back and reread Inside Macintosh and Knaster again. There is NO WAY that a dereference of a pointer is going to move memory, and no way that a string of simple dereferences is ever going to cause a problem. -- -- David Phillip Oster - Note new signature. Old one has gone Bye Bye. -- oster@well.sf.ca.us = {backbone}!well!oster
carlton@aldebaran (Mike Carlton) (11/14/90)
In article <21635@well.sf.ca.us> oster@well.sf.ca.us (David Phillip Oster) writes: >In article <8068@adobe.UUCP> hawley@adobe.UUCP (Steve Hawley) writes: >_>In article <PHILS.90Nov7104254@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >_>>#define ScreenDepth(gdh) ((**((**gdh).gdPMap)).pixelSize) >_>>#define MaxColors(gdh) (1L<<ScreenDepth(gdh)) > >_>>where gdh is a GDHandle (graphic device handle). > >_>Phil -- if your handle is not locked, isn't there a potential problem with >_>the order of evaluation of the dereferences --especially in a context that >_>may move memory? > >_>Steve Hawley >Steve, you should go back and reread Inside Macintosh and Knaster again. >There is NO WAY that a dereference of a pointer is going to move memory, >and no way that a string of simple dereferences is ever going to cause a >problem. >-- >-- David Phillip Oster - Note new signature. Old one has gone Bye Bye. >-- oster@well.sf.ca.us = {backbone}!well!oster But there is a potential problem if you use the macro on the LHS of an assignment with an unlocked handle, i.e. ScreenDepth(someGraphicHandle) = SomeCallThatMovesMemory(42); This is a classic gotcha for newcomers to Mac programming and is likely what Steve was referring to. For those that haven't seen this many times before, the problem is that the compiler is allowed to dereference the handle before making the procedure call, but the dereferenced value will be bogus if the call does have to move memory. Cheers, Mike Carlton, UC Berkeley Computer Science ~ carlton@ernie.berkeley.edu ...!ucbvax!ernie!carlton Manana