rokicki@Navajo.UUCP (06/19/86)
I just got back on the net (I was in Texas for ten days) so I could post this . . . Scenerio: I have a custom 640x400 one-bit-deep screen, with a full 640x400 backdrop window with no borders. I have attached several gadgets to the screen (Boolean and string gadgets) . . . this way, I can use these gadgets and the default Intuition screen depth and dragging gadgets at the same time in the top ten raster lines of the display. The problem: I drag my custom screen down, exposing the Workbench screen. I select a window in the Workbench screen, and then hit one of the string gadgets on the custom screen. THE GADGET IS REDRAWN ON THE TOP OF THE WORKBENCH SCREEN! When I hit the string gadgets after selecting my backdrop window, it is drawn correctly in my custom screen. This is all under 1.1; for some reason, the gadgets don't even appear under 1.2, and the machine crashes when the invisible gadgets are selected. This is driving me up a wall; any help or suggestions would be appreciated. I could put the gadgets in the backdrop window; the problem with this is I then have to implement the screen dragging and depth arrangement myself. See you at the BADGE meeting! ---tom
jimm@amiga.UUCP (Jim Mackraz) (06/20/86)
In article <675@Navajo.ARPA> rokicki@Navajo.ARPA (Tomas Rokicki) writes: >I just got back on the net (I was in Texas for ten days) so I could >post this . . . > >Scenerio: I have a custom 640x400 one-bit-deep screen, with a full >640x400 backdrop window with no borders. I have attached several >gadgets to the screen (Boolean and string gadgets) . . . > >The problem: ... [description] > >This is driving me up a wall; any help or suggestions would be appreciated. >I could put the gadgets in the backdrop window; the problem with this is >I then have to implement the screen dragging and depth arrangement myself. I'm sorry, but you cannot have application gadgets attached to screens. I realize that there are good reasons to want to do so, and one can imagine schemes which would support it. Future editions of the documentation will make this limitation clear. Using backdrop windows is your best bet. Some programs exhibit a "pause" mode where the backdrop window (which normally covers the screen bar) will shrink to expose the screenbar and system gadgets, so the user can drag/arrange the screen. Doing your own depth gadgets is trivial. Doing a screen dragger is easy, but it will not behave identical to the intuition operation, since applications can not today limit the mouse pointer travel. I hope you find a creative solution. jimm
higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (06/21/86)
In article <675@Navajo.ARPA> rokicki@Navajo.ARPA (Tomas Rokicki) writes: >Scenerio: I have a custom 640x400 one-bit-deep screen, with a full >640x400 backdrop window with no borders. I have attached several >gadgets to the screen (Boolean and string gadgets) . . . >The problem: I drag my custom screen down, exposing the Workbench >screen. I select a window in the Workbench screen, and then hit one >of the string gadgets on the custom screen. THE GADGET IS REDRAWN ON >THE TOP OF THE WORKBENCH SCREEN! When I hit the string gadgets after >selecting my backdrop window, it is drawn correctly in my custom screen. >This is all under 1.1; for some reason, the gadgets don't even appear >under 1.2, and the machine crashes when the invisible gadgets are selected. Dear Tom: I hate to disappoint you, but Screen gadgets do NOT WORK, period, and support for them has basically been removed in 1.2 (correct me if I'm wrong Jim M). Yes, you'll have to stick them on the backdrop window instead. Moral: ignore the Intuition manual's mentions of attaching gadgets to screens. Question though: doesn't it peeve you that Intuition needs a rastport for the screen (32K for interlace 1 bit plane - CHOMP) and then another 32K and change for the backdrop window! Seems like a waste. I probably don't understand all the implications, but I think if the screen were treated like a Layer on a view, backdrop windows would be unecessary, because SMART_REFRESH would handle all the overlapping of things. Paul Higginbottom. Disclaimer: I do not work for Commodore, and my opinions are my own.
jimm@amiga.UUCP (Jim Mackraz) (06/22/86)
In article <432@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes: >In article <675@Navajo.ARPA> rokicki@Navajo.ARPA (Tomas Rokicki) writes: >>Scenerio: I have a custom 640x400 one-bit-deep screen, with a full >>640x400 backdrop window with no borders. I have attached several >>gadgets to the screen (Boolean and string gadgets) . . . > >Dear Tom: > > I hate to disappoint you, but Screen gadgets do NOT WORK, period, >and support for them has basically been removed in 1.2 (correct me if I'm >wrong Jim M). > Yes, you'll have to stick them on the backdrop window instead. That's right. >Moral: ignore the Intuition manual's mentions of attaching gadgets to screens. That's a good idea, but I wouldn't call it the Moral. >Question though: doesn't it peeve you that Intuition needs a rastport for >the screen (32K for interlace 1 bit plane - CHOMP) and then another 32K and >change for the backdrop window! Seems like a waste. I probably don't >understand all the implications, but I think if the screen were treated like >a Layer on a view, backdrop windows would be unecessary, because SMART_REFRESH >would handle all the overlapping of things. > Bull Cookies!! A RastPort is 100 bytes. The screen Raster (*RastPort->BitMap->Planes[i]) is indeed 32000 bytes (for 640x400). The amount of memory for a backdrop window (beyond window and layer overhead and the 100 byte RastPort) is determined by its refresh type. Simple Refresh -- No, never, none "pixel" bits get allocated no matter what. Such a backdrop window is typically used for input and gadgets. Smart Refresh -- the obscured portion of your backdrop window is saved offscreen in a chain of little bitmaps whose net pixel total reaches the area of the entire window (could be 32000) when the entire window is obscured. Lots of windows dicing up the screen can cause a great number of bitmaps to be used, which can imply a considerable amount of memory overhead in that chain of bitmaps (actually called ClipRects). The reason you might tolerate this is to benefit from the automatic redrawing of the contents of the backdrop window when obscured portions are exposed (window changes or requesters). Good, if you have backdrop rendering that is time consuming to reproduce. Super Bitmap -- Only in this case is a 32000 byte off-screen buffer required. This is rarely required for a backdrop window. Full Screen applications can try the following (which in 1.2 can be applied more sanely to the area of the title bar). open a custom bit map screen. (use SCREENQUIET in 1.2) open a full screen backdrop smart refresh window. you can now render into your screen's rastport a couple of ways: 1- render through the window's rastport, which incurs (trivial) clipping overhead. useful if you need clipping done 2- render through the screen's rastport. this is absolutely fast (benefits from hardware-assist linedraw, blitter, etc.) and incurs no clipping overhead. 3- turn them bits on and off by yerself (i.e., modify the values in the custom bit map). Good for Intro. to Graphics 101 students, paint programs, Freemap, digitizers, cheapo ports from IBM PC's, and ???. the nice part is that if you want to put up a requester or some window (like a control panel or pallette) you just cease methods 2 and 3, and your imaging done with these "low-level" methods is saved and restored just as you would expect the rendering done by method 1 into a smart refresh window to be. Hope this is interesting. jimm