jordan@unix.cis.pitt.edu (Kenneth D Jordan) (04/15/91)
In the course of writing various scientific applications I've often required double buffering for my animations. The problem is that I've never been able to successfully attach gadgets to the active window nor have I been able to open another window or requester. In the past I simply avoided the problem by restricting user interation to menu bars (which was consistent with those applications). Now, however, I want and need the other features of Intuition. Briefly, my code allocates and initializes two RastPorts and BitMaps ala the RKM, opens a custom screen with the CUSTOMBITMAP flag set, and opens a window on that screen. (The actual code is quite large, and extracting the relevant portions into a small test case is rather painful.) Maintaining a pointer to the RastPort to be used for rendering is sufficient to make use of the various graphics and Intuition system functions which require a pointer to a RastPort. My problem arises when calling other functions such as OpenRequester, OpenWindow, and AddGadget, which require something other than the RastPort. These end up appearing anywhere: on the correct RastPort, on the alternate RastPort, or (I think) somewhere else altogether. When opening requesters the border often ends up on the correct RastPort but the gadgets never appear. Letting rp be a pointer to the rendering RastPort (which works for functions which require a ptr to a RastPort) and win be a pointer to the window, I've tried things like win->RPort = rp and win->BorderRPort = rp before opening a requester, but there's no apparent effect. Any suggestions (including pointers to PD code which exhibits gadgets or requesters on double buffered screens) would be greatly appreciated. Please send mail to nystrom@a.psc.edu. Thanks! -------------------------------------------------------------------------------- Nick Nystrom Chemistry Department University of Pittsburgh nystrom@a.psc.edu --------------------------------------------------------------------------------
mitchell@cbmvax.commodore.com (Fred Mitchell - Product Assurance) (04/16/91)
In article <115475@unix.cis.pitt.edu> jordan@unix.cis.pitt.edu (Kenneth D Jordan) writes: >In the course of writing various scientific applications I've often required >double buffering for my animations. The problem is that I've never been able >to successfully attach gadgets to the active window nor have I been able to >open another window or requester. In the past I simply avoided the problem >by restricting user interation to menu bars (which was consistent with those >applications). Now, however, I want and need the other features of Intuition. >... You might try using the 'double-screen' technique of double-buffering. You would then have identical sets of gadgets, windows and menus on both screens, and listen to both for input. (Easy enough, both windows on the different screens can share the same Message Port.) You would check the message for the approiate window, hence screen, and do a ScreenToFront() for that particular screen, and update the imagery in the alternate window to match the changes. Tricky, but works. It's too easy for Intuition to get out-of-sync with the RKM double-buffering scheme, because Intuition dosen't support it. For menu operations, you'd want to do a IDCMP_MEMUVERIFY to give you a chance to bring the approiate screen to front before allowing the menu to be displayed. The only disavantage with this method is that dragging the screen down (or pulling another screen to front) becomes a problem. If that is a necessity, you'll have to add a gadget to turn on/off double-buffering to allow that. >Nick Nystrom -Mitchell (mitchell@cbmvax.UUCP) /// /// /// /// /// /// All opinions expressed are my own. Period. \\\/// \\\/// \\\/// Strong.Dreams.Reign.Here \XX/ \XX/ \XX/ ===========================================================================
forgeas@swinjm.UUCP (Jean-Michel Forgeas) (04/16/91)
In article <115475@unix.cis.pitt.edu>, Kenneth D Jordan writes: > My problem arises when calling other functions such as OpenRequester, > [..] When opening requesters > the border often ends up on the correct RastPort but the gadgets never appear. > Letting rp be a pointer to the rendering RastPort (which works for functions > which require a ptr to a RastPort) and win be a pointer to the window, I've > tried things like win->RPort = rp and win->BorderRPort = rp before opening a > requester, but there's no apparent effect. RastPorts are not the thing, just the bitplanes of the display. You need only to swap pointers to the new set of bitplanes into the window/screen bitmap, and call MakeVPort() and MrgCop(). Or you can directly swap the copper lists if you want. If you don't want Intuition to draw into your imagery, lock one or all the layers which are into the screen. Intuition will not even move prop gadgets while swaping, and will do it nicely after. Call all your rendering routines inside the 'swap' routine. For example to open a requester: Swap( myOpenRequest ); and here is the myOpenRequest() function: myOpenRequest() { if (Request( Req, WorkWindow )) WaitIDCMP( WorkWindow, REQSET ); } Swap( func ) VOID (*func)(); { LockLayer(); // lock the display BltBitMap(); // copy the display to hidden bitmap WorkWindow->RPort->BitMap = bm; // swap the bitplanes sc->BitMap.Planes[...] = bm->Planes[...]; if (func) (*func)(); // your rendering to hidden bitmap MakeVPort(); // the hidden becomes the display MrgCop(); UnlockLayer(); // unlock the display } That's just the beginning, you have work to do! And think about the fact that the modification of these pointers is perhaps not supported under 2.0 or 5.0... Perhaps Peter Cherna have a better solution ? -- \___/ Jean-Michel Forgeas \-/ cbmvax!cbmehq!cbmfra!swinjm!forgeas | The Software Winery -^- And, where is the universe ?