hockley@ENSU.UCALGARY.CA (Dallas C. Hockley) (05/11/91)
Albert ---> Don't let ol' Tim lead you astray. :-) The _MoveTo is in Global coordinates. Likely the problem you are having is in the origin of the area displayed in the window. The point may *not* be at 0,0. One way of telling is to use a mouse-down event on the point, get the mouse coordinates and convert globaltolocal, and DrawCstring the results. Another that is more flexible and which I have used is to examine the window record to get the content origin (which in the case you described SHOULD be both negative) and compare. The tool calls GetContentOrigin and SetContentOrigin should be able to get your window to where you wnat it for content... Josef Wankerl ---> The hard, slow way, is to use the GS/OS drivers. This is a little wierd, but if you have GS+, and/or can get the source to Transfusion, that is the way that it makes the modem access send/receive commands... Jawaid ---> SPEAKING of you Modemmangaer toolset. Mind tacking the C.Source onto the file? It appears to have been rm'd somehow! :-S I still don't know if it's what I need, so I still can't decide whether or not to have the privledge of paying you! :-) Dallas Dallas Hockley hockley@ensu.ucalgary.ca StarGazer on The Data Systems BBS (403)278-0492
dat33228@uxa.cso.uiuc.edu (Derek A. Taubert) (05/11/91)
In article <9105101730.AA00823@ensu.ucalgary.ca> hockley@ENSU.UCALGARY.CA (Dallas C. Hockley) writes: > >Albert ---> Don't let ol' Tim lead you astray. :-) The _MoveTo is in Global >coordinates. Likely the problem you are having is in the origin of the area Albert ---> Don't let this guy lead you astray. I quote from TBR #3. o Chapter 16 states that the coordinates passed to the LineTo and MoveTo calls should be expressed as global coordinates. In fact, the coordinates must be local and must refer to the GrafPort in Which the drawing or moving takes place. So can we lay this to rest? Please? -- + Derek Taubert --> derek@mrcnext.cso.uiuc.edu + Author of : GScii+ + + dat33228@uxa.cso.uiuc.edu + and the world's most useless + ++++++++++++++++++++++++++++++++++++++++++++++++ desk accessory -> Amaze me + + There are MOUSE technotes? + *******8-) ++++++++++++++++++++++++++++++++ + Ask me about my GS load meter + ^^^^^^^^^^ Marge Simpson +
JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") (05/11/91)
On Fri, 10 May 91 11:30:49 MDT Dallas C. Hockley said: >Albert ---> Don't let ol' Tim lead you astray. :-) The _MoveTo is in Global >coordinates. Likely the problem you are having is in the origin of the area Wrong!! MoveTo takes local coordinates! Refer to toolbox ref vol 3, page 43-2. Vol 2 was in error. The reason the point was down and to the right was because he was drawing in the window's grafport. If you first switch to a grafport that is the full screen, then use global coordinates the drawing will be correct, but still in the wrong grafport. >Josef Wankerl ---> The hard, slow way, is to use the GS/OS drivers. This is >a little wierd, but if you have GS+, and/or can get the source to Transfusion, >that is the way that it makes the modem access send/receive commands... I *WROTE* Transfusion. :-) Using GS/OS is definately not difficult. In fact, it's probably the easiest method to use. However, you're correct in the fact that it's slower than direct access to the firmware. >Dallas >Dallas Hockley >hockley@ensu.ucalgary.ca >StarGazer on The Data Systems BBS (403)278-0492 -- ===> Josef W. Wankerl, Technical Editor for GS+ Magazine BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl ProLine: jwankerl@pro-gsplus |-------------------------------- Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteen
RXBROWN@UALR.BITNET ("MR.FANTASTIC") (05/13/91)
>Wrong!! MoveTo takes local coordinates! Refer to toolbox ref vol 3, >page 43-2. Vol 2 was in error. The reason the point was down and to the >right was because he was drawing in the window's grafport. If you first >switch to a grafport that is the full screen, then use global coordinates >the drawing will be correct, but still in the wrong grafport. > Josef or anyone, Could you please explain a Grafport to me. I read about it in the ref manual, but I did not quite get it. >-- >===> Josef W. Wankerl, Technical Editor for GS+ Magazine > BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl > ProLine: jwankerl@pro-gsplus |-------------------------------- >Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteen Thanks Robert ******************************************************************************** Real: Robert Brown * Profanity is the one language all Academic Computing Services Lab Manager * programmers know best. Bitnet: RXBROWN@UALR * I speak for me, myself, and I!! AOL: ROBPHD * Tires and tax not included,void where Apple //GS the power to be your best. * prohibited. Member FDIC.............. ********************************************************************************
JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") (05/14/91)
On Mon, 13 May 91 10:14:00 CDT MR.FANTASTIC said: >Josef or anyone, > >Could you please explain a Grafport to me. I read about it in the ref manual, >but I did not quite get it. Hmmmm.... The concept of grafport isn't really difficult to understand, but I found it rather hard to explain. Basically a grafport is a place where you can draw things to. The best way to think of a grafport is to think of it as a window. The content area of a window is a grafport. When you draw, you aren't actually drawing to the screen, you are drawing in the grafport. If it so happens that part of your grafport is visable on the screen then what you draw will also appear on the screen. Does that make sense? >Thanks Robert >******************************************************************************* >* >Real: Robert Brown * Profanity is the one language all >Academic Computing Services Lab Manager * programmers know best. >Bitnet: RXBROWN@UALR * I speak for me, myself, and I!! >AOL: ROBPHD * Tires and tax not included,void where >Apple //GS the power to be your best. * prohibited. Member FDIC.............. >******************************************************************************* >* -- ===> Josef W. Wankerl, Technical Editor for GS+ Magazine BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl ProLine: jwankerl@pro-gsplus |-------------------------------- Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteen
unknown@ucscb.UCSC.EDU (The Unknown User) (05/14/91)
In article <9105131923.AA10899@apple.com> JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: .Hmmmm.... The concept of grafport isn't really difficult to understand, .but I found it rather hard to explain. Basically a grafport is a place .where you can draw things to. The best way to think of a grafport is .to think of it as a window. The content area of a window is a grafport. .When you draw, you aren't actually drawing to the screen, you are .drawing in the grafport. If it so happens that part of your grafport .is visable on the screen then what you draw will also appear on the .screen. Does that make sense? This is kind of relevant to this discussion I think.. In the GUI world, the term "window" is used incorrectly.. That is, in respect to how it's used in computer graphics. -- /unknown@ucscb.ucsc.edu Apple IIGS Forever! unknown@cats.ucsc.edu\ |WANT to help get ULTIMA VI //e or GS written?-mail me. CHEAP CD info-mail me.| \ It's a Late Night World.... Of Love /
JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") (05/15/91)
On Tue, 14 May 91 09:26:00 CDT MR.FANTASTIC said: > Ah, it makes very much sence. I must have read over the section when I was >tired. Am I correct in assuming that you can draw to a Grafport before it is >displayed on the screen. Thus increasing the speed of screen updates? Well don't get me wrong... there's a bit more to grafports than my simple explination, but I thought that kind of got the basic idea across. Yes, you can have "offscreen" grafports. You can do all your drawing to the offscreen grafport and nothing will happen on the screen. Then, later when you want it to appear on the screen, you can do a quick PPToPort to copy your offscreen port to a visible one. This is like a caching mechanism. >Robert >******************************************************************************* >* >Real: Robert Brown * Profanity is the one language all >Academic Computing Services Lab Manager * programmers know best. >Bitnet: RXBROWN@UALR * I speak for me, myself, and I!! >AOL: ROBPHD * Tires and tax not included,void where >Apple //GS the power to be your best. * prohibited. Member FDIC.............. >******************************************************************************* >* -- ===> Josef W. Wankerl, Technical Editor for GS+ Magazine BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl ProLine: jwankerl@pro-gsplus |-------------------------------- Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteen
RXBROWN@UALR.BITNET ("MR.FANTASTIC") (05/17/91)
>Well don't get me wrong... there's a bit more to grafports than my >simple explination, but I thought that kind of got the basic idea >across. Yes, you can have "offscreen" grafports. You can do all your >drawing to the offscreen grafport and nothing will happen on the screen. >Then, later when you want it to appear on the screen, you can do a >quick PPToPort to copy your offscreen port to a visible one. This is >like a caching mechanism. > >-- >===> Josef W. Wankerl, Technical Editor for GS+ Magazine > BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl > ProLine: jwankerl@pro-gsplus |-------------------------------- >Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteen I went back and read up on Grafports in the Programmers Intro. Then I read the section on printing. In the printing section they use a Grafport to dump the image of what is to be printed to the printer. I think this is where the initial confusion came from. What else are Grafports used for? Robert ******************************************************************************** Real: Robert Brown * Profanity is the one language all Academic Computing Services Lab Manager * programmers know best. Bitnet: RXBROWN@UALR * I speak for me, myself, and I!! AOL: ROBPHD * Tires and tax not included,void where Apple //GS the power to be your best. * prohibited. Member FDIC.............. ********************************************************************************
acmfiu@serss0.fiu.edu (ACMFIU) (05/18/91)
In article <9105151708.AA15055@apple.com> JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes:
]On Tue, 14 May 91 09:26:00 CDT MR.FANTASTIC said:
]] Ah, it makes very much sence. I must have read over the section when I was
]]tired. Am I correct in assuming that you can draw to a Grafport before it is
]]displayed on the screen. Thus increasing the speed of screen updates?
]
]Well don't get me wrong... there's a bit more to grafports than my
]simple explination, but I thought that kind of got the basic idea
]across. Yes, you can have "offscreen" grafports. You can do all your
]drawing to the offscreen grafport and nothing will happen on the screen.
]Then, later when you want it to appear on the screen, you can do a
]quick PPToPort to copy your offscreen port to a visible one. This is
]like a caching mechanism.
do you want to explain what "quick PPToPort" means. if you ask me, PPToPort
is very slow when it comes to large grafports. do you think ScrollRect is
"quick" also? i sure hope not. i generally use PPToPort on small rectangular
regions i want to copy. i have a window onscreen and in the UserField of the
grafport of this window i have a pointer to the grafport of my off-screen
grafport (see, local variables :).
quickdraw does draw faster to off-screen grafports because it doesn't have
to do the 2/4-bit conversion when drawing stuff on-screen (did i get this
right dave?).
i'm going to write my own ScrollRect and PPToPort (not *real* versions but
will do what i want) within the next week. after i have some people take a
look at the code (i want it *real* fast), i'll post it.
]]Robert
]]******************************************************************************
]]*
]]Real: Robert Brown * Profanity is the one language all
]]Academic Computing Services Lab Manager * programmers know best.
]]Bitnet: RXBROWN@UALR * I speak for me, myself, and I!!
]]AOL: ROBPHD * Tires and tax not included,void where
]]Apple //GS the power to be your best. * prohibited. Member FDIC.............
]]******************************************************************************
]]*
]
]--
]===> Josef W. Wankerl, Technical Editor for GS+ Magazine
] BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl
] ProLine: jwankerl@pro-gsplus |--------------------------------
]Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteendlyons@Apple.COM (David A. Lyons) (05/20/91)
In article <3588@kluge.fiu.edu> acmfiu@serss0.fiu.edu (ACMFIU) writes: >[...] >quickdraw does draw faster to off-screen grafports because it doesn't have >to do the 2/4-bit conversion when drawing stuff on-screen (did i get this >right dave?). As Jim Murphy pointed out, pixel maps are still 2 or 4 bits deep whether they're on the screen or not. As Jawaid pointed out, storing to screen memory happens at 1 MHz, whereas offscreen memory is usually full processor speed. And finally, as I'm pointing out right now, QuickDraw *does* special-case the *screen* for some operations (a few more on ROM 3 than on ROM 1). Offscreen grafports are very useful when your images take much longer to generate than to copy onto the screen. You don't want to regenerate a fractal, for example, every time somebody moves a window so that more of it is visible. If your drawing is straightforward, there's no advantage to using an offscreen grafport. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II System Software Engineer | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie:DAVE.LYONS CompuServe:72177,3233 Internet:dlyons@apple.com My opinions are my own, not Apple's.
acmfiu@serss0.fiu.edu (ACMFIU) (05/21/91)
In article <FE48021780800432@UALR.BITNET> RXBROWN@UALR.BITNET ("MR.FANTASTIC") writes:
]]Well don't get me wrong... there's a bit more to grafports than my
]]simple explination, but I thought that kind of got the basic idea
]]across. Yes, you can have "offscreen" grafports. You can do all your
]]drawing to the offscreen grafport and nothing will happen on the screen.
]]Then, later when you want it to appear on the screen, you can do a
]]quick PPToPort to copy your offscreen port to a visible one. This is
]]like a caching mechanism.
]]
]]--
]]===> Josef W. Wankerl, Technical Editor for GS+ Magazine
]] BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl
]] ProLine: jwankerl@pro-gsplus |--------------------------------
]]Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteen
]
] I went back and read up on Grafports in the Programmers Intro. Then I read
]the section on printing. In the printing section they use a Grafport to dump
]the image of what is to be printed to the printer. I think this is where the
]initial confusion came from. What else are Grafports used for?
]
]Robert
]******************************************************************************
]Real: Robert Brown * Profanity is the one language all
]Academic Computing Services Lab Manager * programmers know best.
]Bitnet: RXBROWN@UALR * I speak for me, myself, and I!!
]AOL: ROBPHD * Tires and tax not included,void where
]Apple //GS the power to be your best. * prohibited. Member FDIC..............
]******************************************************************************
i think the reason you first need to print the image to a grafport is
because you can't send commands like DrawText directly to the print manager.
you have to manually construct what the page will look like in memory. once
you construct this bit image, then you send this image off to the printer.
grafports aren't "used" specially for anything particularly. all drawing
by QD is done to a grafport. a grafport is just some area defined in memory
where QD will draw stuff, i.e. LineTo, DrawChar, FillRect, etc. i think
if you understand the relationship between QD and GrafPorts then you'll
be all set. now, the Window Manager uses grafports. however, notice that
you need QD started in order for Window Manager to work.
the idea of a grafport stifled me at first. however, write a few programs
(preferably in asm so you can step through with GSBug) and see what happens
as you do QD calls to the grafport.
albert