Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ames!ncar!boulder!tramp!hassell From: hassell@tramp.Colorado.EDU (Christopher Hassell) Newsgroups: comp.sys.amiga.tech Subject: Re: Double-Buffering in a window Summary: Ahh..... what little we say before we know Message-ID: <15547@boulder.Colorado.EDU> Date: 11 Jan 90 20:16:01 GMT References: <897@mindlink.UUCP> <1990Jan10.134148.21435@gdt.bath.ac.uk> Sender: news@boulder.Colorado.EDU Reply-To: hassell@tramp.Colorado.EDU (Christopher Hassell) Organization: (Let's see, I'm positive .. I've got ... ) Lines: 56 <1990Jan10.134148.21435@gdt.bath.ac.uk> mapjilg@gdr.bath.ac.uk (J I L Gold) : # In article <897@mindlink.UUCP> a464@mindlink.UUCP (Bruce Dawson) writes: # > # > All of the windows in a screen share the same bitmap (at least for their # >visible portions, which is what you're interested in). So, if you want to #>double buffer one window, you've got to double buffer all of them. The entire #>screen gets flipped all at once. So, unless you first copy the contents of the #>entire screen to the hidden buffer, the other windows are going to flashing on # >and off as you flip bitmaps. # > # # However you do have access to the layers through CopySBitMap() and SyncSBitMap() # which I'm reliably informed do the job nicely! # -- # J.Gold | mapjilg@uk.ac.bath.gdr # Those ARE valid software techniques. I'm not giving any advice here... just dreaming a bit: But ..... it would be nice A: if the copper could blit stuff around CONSTANTLY (as in every scan) from a different and wierd portion of separate memory B: if there was a simple option in the copper which allowed you to SIMPLY CHANGE THE SCAN-ADDRESS WITHIN A SCAN-LINE AND WORSE. If/When the amiga basically cannot keep its innards together and it explodes into a multiprocessing machine (which should be alot more blase' to make in la future).... wouldn't it be nice to LITERALLY have "windows" into memory.... windows into displays that are configured who-knows-where in that Meg or two your A500 enjoys? So much for problems with multitasking and display-haggling... they wouldn't even need to be resolved by a window manager... below a certain level... they, screen conflicts, would simply never occur because the screen only chose to listen to specific parts of any program's actual workings. I like the idea personally... if I get enough money.. I might even try to hack something like that together on a little dead Apple //+ (where everything is socketed). It would be mucho nicer on the amiga, of course. Your arguments are valid for what should be done. I believe that there are "windowing" graphics-management chips out there which do exactly what I said... but they are definately high-end and somewhat restrictive. Latuh. # -- # #------------------------------------------------------------------------------# # # Paranoia is thinking that if something CAN'T go wrong it will still go wrong.# # #------------------------------------------------------------------------------# # # J.Gold | mapjilg@uk.ac.bath.gdr # ### C>H> ### { uunet!rutgers!sunybcs , ncar , nbires } !boulder!tramp!hassell