🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.jbuilder.java.language
Article #8329

Re: DESPERATE !!!

#8329
From: John McGrath TeamB
Date: Sat, 31 Mar 2001 09:05
90 lines
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.60
References: <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