shatara@memit.dec.com (Chris: 223-8753, TECHNOLOGY OFFICE, MLO1-4/T35) (07/01/89)
re Note from Dave Lyons >>You can use GetPortRect to find out which part of the window you're scrolled >>to, or you can get the bounding box of the update region. More details on >>request--gotta take off! > >Let me try this once more, not under time pressure this time. > >Inside your content-draw routine, BeginUpdate has already been called by the >system, so what you want to do is get the bouding box of the VisRegion (try >GetVisHandle()^^.bBox to get the smallest rectangle that encloses the part of >the window that needs to be updated. > Dave, you cought my interest on this one! As usual I have several questions as I tried implementing this and it didn't quite work as I would have expected it to. 1. I am assuming that the Window Definition Procedure pointed to by wContDefProc is used for updating the window contents as well as drawing them for the first time. 2. Your statement above implies that BeginUpdate (and hence EndUpdate) has has already been called when I unter the Window Def Procedure after an update event. Is this true. 3. re 1. above, when the window is first created on the desktop, calling GetVisHandle()^^.bBOX will yield a rectangle of what size? ..I would expect (hope) the size of the content region. 4. How does GetVIsHandle differentiate from the region needing to be updated on the mainscreen and a region of a window on the screen. Happy Forth! Regards, chris Shatara
dlyons@Apple.COM (David Lyons) (07/02/89)
In article <8907011229.AA12157@decwrl.dec.com> shatara@memit.dec.com (Chris: 223-8753, TECHNOLOGY OFFICE, MLO1-4/T35) writes: >Dave, you cought my interest on this one! As usual I have several >questions as I tried implementing this and it didn't quite work as I would >have expected it to. > >1. I am assuming that the Window Definition Procedure pointed to by > wContDefProc is used for updating the window contents as well as > drawing them for the first time. Yes; drawing the content "the first time" is not distinguished from drawing it or part of it later. When you create a window, the update region is initially wide-open, so an update event occurs automatically. >2. Your statement above implies that BeginUpdate (and hence EndUpdate) has > has already been called when I unter the Window Def Procedure after an > update event. Is this true. Yes. If you're using TaskMaster, here's what happens: TaskMaster gets an Update event (by calling GetNextEvent internally). It notices that your window has a nonzero entry for wContDefProc, so it calls BeginUpdate on your window, calls your wContDefProc procedure, and finally calls EndUpdate on your window. If you're *not* using TaskMaster (or if your window has a zero value for wContDefProc), then your program will receive Update events itself, and you should call BeginUpdate and EndUpdate yourself. Note that the name for the "wContDefProc" routine is the "Draw content routine," not to be confused with a "window definition procedure" (or "window defproc"), used for custom windows. (If you want a triangle- shaped window, for example, you'd have to write a window defproc.) >3. re 1. above, when the window is first created on the desktop, calling > GetVisHandle()^^.bBOX will yield a rectangle of what size? ..I would > expect (hope) the size of the content region. Well, the most precise statement I can make about GetVisHandle()^^.bBox is that it's the bounding rectangle of the window's VisRegion. Right after you create a window *in front* of all other windows, the VisRegion will be the same as the Content Region, *BUT* the VisRegion is in the window's local coordinate system, and the Content Region is in global coordinates. Be careful. >4. How does GetVIsHandle differentiate from the region needing to be > updated on the mainscreen and a region of a window on the screen. I don't understand the question. The VisRegion just indicates which parts of the window are visible. Any part that is off the screen or behind another window won't be in the VisRegion. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
tribby@hpindda.HP.COM (David Tribby) (07/05/89)
Dave Lyons explains how to update only the part of a window that needs it... > what you want to do is get the bouding box of the VisRegion (try >GetVisHandle()^^.bBox to get the smallest rectangle that encloses the part of >the window that needs to be updated. I tried this over the weekend and was VERY pleased with the speedup! One problem I had to overcome: the TML Pascal unit for QuickDraw incorrectly lists GetVisHandle as a PROCEDURE with a parameter, rather than a FUNCTION that returns the value. Using the original PROCEDURE returned garbage values. I defined a FUNCTION GetVisHandle2 of the proper type, bound to the same Tool. Then it worked fine. --Dave Tribby - - - - - ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribby
shatara@memit.dec.com (Chris Shatara) (07/07/89)
>I tried this over the weekend and was VERY pleased with the speedup! One >problem I had to overcome: the TML Pascal unit for QuickDraw incorrectly >lists GetVisHandle as a PROCEDURE with a parameter, rather than a >FUNCTION that returns the value. Using the original PROCEDURE returned >garbage values. I defined a FUNCTION GetVisHandle2 of the proper type, >bound to the same Tool. Then it worked fine. I ran into the same thing and with the help of Dave Lyons found this "feature" in TML pascal. I'm currently using an older version of TML, V1.1 i think. Does anyone one know if this was fixed in later versions? If not, then it could still be there in the soon to be released V2.0. -------------------------------------------------------------------- Chris Shatara shatara@memit.dec.com --or-- ...!decwrl!memit.dec.com!shatara --or-- shatara%memit.dec@decwrl.dec.com { a frustrated manager who misses real engineering } --------------------------------------------------------------------
tribby@hpindda.HP.COM (David Tribby) (07/07/89)
The original poster, Jeff Hartkopf, asked me to be a little more explicit
in how I used the GetVisHandle call, so here are more details. The procedure
I'm writing plots a waveform from DOC memory to the screen; since those
waves can be 32K bytes long, it can take a long time to plot the entire
thing, even with plotting only every 8th byte! So I use the size of the
visible window to cut back on the amount of plotting that needs to be done.
Here's part of the code...
{ Redeclare GetVisHandle, since TML got it wrong in 1.5 QDIntf}
FUNCTION GetVisHandle1: RgnHandle; Tool 4,201;
{$LongGlobals+} { Procedure may be called without data reg set properly }
PROCEDURE PlotWave(doc_index: INTEGER);
VAR
... { Several variables declared }
min_h, max_h: INTEGER; { Horiz limits, in local coordinates }
vis_region_handle: RgnHandle; { Visible region handle }
BEGIN { PlotWave }
...
{ Get waveform out of DOC memory, determine stepping size, & calculate }
{ limits of horizontal axis in local coordinates (min_h & max_h). }
...
{ Determine how much of what we have to plot is visible }
vis_region_handle := GetVisHandle1;
WITH vis_region_handle^^.rgnBbox DO
BEGIN
IF left > min_h THEN min_h := left;
IF right < max_h THEN max_h := right;
END;
{ Plot the wave in the window }
...
END; { PlotWave }
{$LongGlobals-}
--Dave Tribby
ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribby