ejkst@cisunx.UUCP (Eric J. Kennedy) (08/09/88)
This bug is driving me crazy. In case you all don't know about it, let me describe what little I know. It seems that when you have several screens of different resolutions up at the same time, and flip between them, you can get strange errors, usually resulting in crashes, sometimes with some pretty spectacular fireworks. I think it happens when you have interlaced and non-interlaced screens at the same time, because sometimes the interlaced screen comes up non-interlaced, with the bottom half of the screen disappearing into your top desk drawer. I've seen this bug discussed here before, so I know it's not exactly news. What I want to know is can anyone describe a little more exactly the conditions to avoid? I'm afraid to run several applications that open custom screens at once, for fear of crashing due to this bug. Has anybody figured out a fix or a patch? I suppose it can't be fixed permanantly until 1.4, right? How about a patch like SetAlert? Something! Anything! [I've just spent the last hour preparing my data with Superbase, graphing it with MultiPlot, etc., etc.; in walks my professor to take a look at some of my results; "Here you go, look at these graphs...Look at that nice...red...blinking...box..."] Thanks, -- ------------ Eric Kennedy ejkst@cisunx.UUCP
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/10/88)
Yes, the situation is that you have two interlaced screens up and one
non-interlaced screen up. Dragging a screen down always works, flipping
them around with the front and back gadgets/keys sometimes results in
fried copper lists. If you notice this and immediately reflip the screen
to a "good" state you can often recover. Basically, drag down the front
screen to expose the rear screen and then flip them.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.cmcmanis%pepper@Sun.COM (Chuck McManis) (08/22/88)
In article <8808200650.AA14865@jade.berkeley.edu> (Jonathan Crone) writes: >Hi all, could someone Email me the exact situation that >causes that problem that Intuition has with interlaced and >non interlaced screens??? >I'm trying to isolate a bug in something and I'm not sure what >it is or whether its a problem in Intuition.... It isn't Intuition :-). Actually, the only bug that I know of has to do with ReMakeDisplay() when operating on interlace screens that aren't the front most screen. To see this in action open two interlace and one non interlace screen and then use the screen to {front|back} gadgets in the corners to rearrange them. Eventually you will see a screen that has obviously got a broken copper list. Do you call ReMakeDisplay() in your code? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
jimm@amiga.UUCP (Jim Mackraz) (08/24/88)
In article <65150@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: )In article <8808200650.AA14865@jade.berkeley.edu> (Jonathan Crone) writes: )>Hi all, could someone Email me the exact situation that )>causes that problem that Intuition has with interlaced and )>non interlaced screens??? )>I'm trying to isolate a bug in something and I'm not sure what )>it is or whether its a problem in Intuition.... ) )It isn't Intuition :-). Actually, the only bug that I know of has to do )with ReMakeDisplay() when operating on interlace screens that aren't the )front most screen. To see this in action open two interlace and one non )interlace screen and then use the screen to {front|back} gadgets in the )corners to rearrange them. Eventually you will see a screen that has )obviously got a broken copper list. Do you call ReMakeDisplay() in your )code? ) )--Chuck McManis Well, it is Intuition, Remake/RethinkDisplay(). What happens in RethinkDisplay() is that only those copper lists that need changing are to be rebuilt. When dragging a screen, this is at most two screens: the one getting taller and the one getting shorter (the two on either side of the "seam" being dragged"). Now what happens is this: RemakeDisplay() creates a single new copper list for an interlaced viewport if that viewport is hidden and the whole display is non-interlaced. When you pop that screen to the front, RethinkDisplay() is called. The Viewport height hasn't changed, but everyone's copper lists are remade when the screen switches into interlaced mode. The problem happens when in the intervening time, some other interlaced screen appears, the display goes into interlaced mode, and our interlaced viewport's non-interlaced copper list still hasn't been rebuilt. Now when it pops to the front, it passes the height change check, it passes the interlace-change check, so it isn't remade. The bug is that VP_HIDE changing hasn't caused a further incentive to rebuild the copper list for our interlaced screens viewport. Then some magic happens when you use copper lists created for the wrong purpose. Note that a key point is that the mode of the View a viewport is hanging off of at the time of MakeVPort() determines how the copper lists will be built, in particular, two (for interlace) or one. So although the bug is in RethinkDisplay(), the problem arises when you call RemakeDisplay(). So don't do that if you can help it. A hack: try jamming a zero into the DHeight field of each screens viewport which is showing VP_HIDE in its modes, after you RemakeDisplay(). That way, when visible, RethinkDisplay() will rebuild its coppuppies. This hack is by no means guaranteed to work in V1.4, but I'll try. For that matter, it isn't guaranteed to work in V1.2/V1.3. It's just a thought. Better yet is not to call RemakeDisplay() if you don't have to, and you usually don't. RemakeDisplay() is only used to construct new copper lists for every viewport. You rarely need to do that. The standard sequence when you want to screw over your screen's viewport is: MakeScreen( screen ); /* construct new coppups for my vp */ RethinkDisplay(); /* mrgcop and loadview */ Do this, over the hack, if at all possible. jimm -- Jim Mackraz, I and I Computing amiga!jimm BIX:jmackraz Opinions are my own. Comments regarding the Amiga operating system, and all others, are not to be taken as Commodore official policy.