[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: How to pass arguments by reference in a function

seebs

7/27/2007 7:45:00 PM

In message <026a01c7d085$106a05c0$6442a8c0@musicbox>, "Bill Kelly" writes:
>Incidentally, I do recall one interesting use of this XOR swap
>technique.

>I believe this is how GUI menus were drawn on the screen on the
>Amiga. When you'd click the mouse to get a menu, the system
>would allocate off-screen bitmap memory, and render the menu
>into the off-screen bitmap. Then it would XOR-swap the off-screen
>rendered menu, with the location on the screen where the menu
>would be displayed. Thus preserving the pixels from the screen
>that would be obscured by the menu, so that the pixels could
>be restored when the menu was dismissed.

Interesting. There were a few different ways; you could request
automatic backing store, or you could do it yourself and get notifications,
but it was mostly transparent.

>Pretty neat trick, since it avoided allocating an extra buffer
>to store the obscured screen pixels. (And it was fast, because
>the Amiga bitmap blitter supported logical raster op's including
>XOR, etc.)

Except it does allocate a buffer, really. I don't recall the details
anymore.

-s

1 Answer

Bill Kelly

7/27/2007 8:29:00 PM

0

From: "Peter Seebach" <seebs@seebs.net>
>
> In message <026a01c7d085$106a05c0$6442a8c0@musicbox>, "Bill Kelly" writes:
>>Incidentally, I do recall one interesting use of this XOR swap
>>technique.
>
>>I believe this is how GUI menus were drawn on the screen on the
>>Amiga. When you'd click the mouse to get a menu, the system
>>would allocate off-screen bitmap memory, and render the menu
>>into the off-screen bitmap. Then it would XOR-swap the off-screen
>>rendered menu, with the location on the screen where the menu
>>would be displayed. Thus preserving the pixels from the screen
>>that would be obscured by the menu, so that the pixels could
>>be restored when the menu was dismissed.
>
> Interesting. There were a few different ways; you could request
> automatic backing store, or you could do it yourself and get notifications,
> but it was mostly transparent.

Menus were handled differently than windows, as I recall.
(For windows, yes, there were three buffering/backing-store
modes: SIMPLE_REFRESH, SMART_REFRESH, and SUPER_BITMAP. But
menus, if I recall correctly, were not really windows. They
locked the layers and performed the XOR trick as described above.)


>>Pretty neat trick, since it avoided allocating an extra buffer
>>to store the obscured screen pixels. (And it was fast, because
>>the Amiga bitmap blitter supported logical raster op's including
>>XOR, etc.)
>
> Except it does allocate a buffer, really. I don't recall the details
> anymore.

Right, just one buffer though. The neat trick was that with
just one buffer, you could fully render the menu off-screen,
then swap it on-screen, while simultaneously preserving the
on-screen pixels for later restoration.

What was kind of fun, is if your screen had enough bitplanes,
you could actually *see* the XOR trick in transition, if the
video beam happened to catch the screen region where the XOR
was occurring, and only some of the bitplanes had been processed
yet. If the screen had lots of bitplanes, and a large menu
was dropping down, you'd get a momentary funky colorful flash
as the menu/screen pixels were being XOR swapped into the
off-screen buffer.


Regards,

Bill