[4490] in java-interest
Re: Transparent Applet, or controls and AWT
daemon@ATHENA.MIT.EDU (Neil Bartlett)
Tue Jan 2 22:28:56 1996
Date: Tue, 2 Jan 1996 20:31:57 -0500
To: java-interest@java.sun.com
From: Neil Bartlett <neilb@the-wire.com>
Salute Michel,
I hate to disagree of forums - it always gives the wrong impression :-)
But in the spirit of a friendly discussion here goes anyhow.
Michel Meyer wrote
> Neil Bartlett wrote
>>My solution is that the JDK sould provide the developers with a way of
>>reading the image that is under the current panel rather than just drawing a
>>rectangle over the top of the background.
>
>I don't think this is a good solution. It goes against the framework philosphy.
>
>the redraw of a component should happen in the following order:
>
>1. container receives a redraw order.
>2. It redraws itself (begining with an erase only if it really whishes it,
>and that's currently impossible)
>3. It calls the draw method of its subcomponents ...
>
>and so on for any subcomponent which is a container...
I agree with the 1-2-3 scheme. This is pretty much what happens today in the
repaint->update->paint cycle.
The point I was making was more to do with flicker free double-buffered
animations. If we follow the above 1-2-3 scheme we will get a flicker as the
background image redraw or erase happens - since it is not 'hidden' from the
user's eyes.
Conversely if the background image is not redrawn then the animation will
obviously destroy the underlying image as the animation proceeds.
So somehow the background image must be redrawn without the user seeing the
redraw if we want to be able to do flicker free animations.
I would like to see a scheme that allows for the transparency and allows for
double-buffering. I don't think the 1-2-3 scheme above achieves this aim,
although, as always, I am willing to be convinced :-)
I think that either the background image must be available to be drawn into
the off-screen image - or the off-screen image must be reprimed each time
with the background image. Either way there must be some mechanism for the
background image to get into the off-screen image. If the background image
is draw directly into the on-screen image followed by a draw of the
off-screen image then the user will see the flicker. This was the point I
was making.
I think that it could be achieved without the user program/applet actually
having hold of a handle to the background image and I would definitely
support that as a goal to be achieved.
I believe the possiblity of using colour planes to lock the underlying image
in place will reduce the colours available to the HTML and the Java applet
too much. 8-bit color systems are still predominant on peoples desktops and
people will want to display 256 colour images on their homepage backgrounds.
I look forward to more discussion on this point,
Neil Bartlett
Co-author of upcoming book, The Java Explorer
neilb@the-wire.com 416-769-1851
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
