Article View: borland.public.jbuilder.java.language
Article #8329Re: DESPERATE !!!
From: John McGrath TeamB
Date: Sat, 31 Mar 2001 09:05
Date: Sat, 31 Mar 2001 09:05
90 lines
5217 bytes
5217 bytes
On 30 Mar 2001 10:21:57 -0800, Joi Ellis [TeamB] wrote:
> > If I erase the last line "TD=false" it works fine.
> > But I need that line because I want to draw the image only once.
>
> Hrm. I don't think you can really do this. I think your paint()
> method is supposed to assume that its entire coordinate space has
> been erased and it needs to rebuild it all. You have to redraw
> the whole image every time.
This is true. If you tell your paint method to only paint the image
the first time that it is called, then if another window is dragged in
front of the image, it will not be repainted when the image is exposed.
In almost all cases, a paint() method should just paint itself, and
leave it up to the windowing system to decide when to do that.
You were also very close in the previous message when you mentioned
making sure that the image is completely loaded first. If that were
done, then Carlos would probably see the image when the paint() method
is called the first time. However, it would revert to black if it were
obscured and then exposed again.
The java.awt.image APIs are rather somewhat of a marvel. Although they
make you think that you are simply taking a simple collection of pixels
and transferring them the display, there is a *lot* more that actually
goes on. Here is what is happening:
When the Pintar Applet is first made visible, the graphics system calls
the Applet's paint() method, and it first runs the following code since
(TD == true):
TableroGif = getImage(getCodeBase(), "Tablero.gif");
Tablero_Buffer.drawImage (TableroGif, 0, 0, this);
The first line creates an Image object, but it does *not* actually
begin loading the image. It just saves the URL where the image is
stored.
The second line tells it to draw the Image. But since the image has
not actually been loaded yet it cannot be drawn, so it starts a
background thread to load the image. Take note that the type of the
last argument to the drawImage() method if of interface ImageObserver.
The argument passed is "this", which is the Applet. Applet extends
Component which implements ImageObserver.
When the image loading thread gets around to loading part of the image,
it notifies the ImageObserver by calling its imageUpdate() method. And
the default implementation (defined in Component) calls repaint(). The
repaint() pushes an event onto the event queue, and when that event is
dispatched, it results in your paint() method being called again.
The image loading thread calls imageUpdate() as soon as any information
is available about the image: width, height, other properties, or some
of the actual pixel data. The imageUpdate() method implementation in
Component returns true if the image has not been completely, which
indicates to the image thread that it wishes to be called again. This
process is what causes the incremental painting effect that you have
seen in Java Applets, as well as in browsers.
The first time that your paint() method is called, there is no image
available to paint. And since your code does not try to paint the
image after the first call, the image never gets painted.
You have very little control over when the paint() method will be
called. Deciding that is the job of the AWT. Your paint() method
should be viewed as a slave to the AWT, and it should generally just
paint the component when it is asked. Nothing more, nothing less.
A few other notes:
As far as I can see, there is little reason to defer the creation of
the TableroGif Image until the first paint() call. As noted above,
this just stores the URL for the image, so you may as well do this in
the init() method.
I am also not sure what you are trying to do with the TableroImg Image.
If the idea is to buffer the image so that it does not have to be
loaded from disk (or the network) each time, that is not necessary
either. I believe the Image data is buffered automatically. If you
think the image rendering process is complex, try looking into the
world of ImageProducers, ImageConsumers, BufferedImageSources, etc.
--
Regards,
John McGrath [TeamB]
---------------------------------------------------
Before sending me e-mail, please read:
http://www.JPMcGrath.net/newsgroups/e-mail.html
Technical Details
Message-ID:
<MPG.152f3e28f1c3944298a0dc@forums.borland.com>Path:
arc1-ca.pugleaf.net!supernews.google.com!sn-xit-03!supernews.com!newsfeed.wirehub.nl!news.algonet.se!algonet!newsfeed1.uni2.dk!newssuck.uni2.dk!dnews!209.92.40.60References:
<3AC361A6.21A4F47E@rslcom.es> <3ac36a85_1@dnews> <3AC46592.98908578@rslcom.es> <3ac4cec4_2@dnews>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f74b3,e3fc9de084362442 X-Google-Attributes: gidf74b3,public X-Google-ArrivalTime: 2001-03-31 01:44:02 PST From: John McGrath [TeamB] <ng-b@JPMcGrath.net> Newsgroups: borland.public.jbuilder.java.language Subject: Re: DESPERATE !!! Date: Sat, 31 Mar 2001 04:05:27 -0500 Message-ID: <MPG.152f3e28f1c3944298a0dc@forums.borland.com> References: <3AC361A6.21A4F47E@rslcom.es> <3ac36a85_1@dnews> <3AC46592.98908578@rslcom.es> <3ac4cec4_2@dnews> X-Newsreader: MicroPlanet Gravity v2.30 NNTP-Posting-Host: 209.92.40.60 X-Trace: 31 Mar 2001 01:00:48 -0800, 209.92.40.60 Lines: 90 X-Authenticated-User: jpmcgrath Path: arc1-ca.pugleaf.net!supernews.google.com!sn-xit-03!supernews.com!newsfeed.wirehub.nl!news.algonet.se!algonet!newsfeed1.uni2.dk!newssuck.uni2.dk!dnews!209.92.40.60