Simple Draw Image

[Brian D. Elliott]

I am having a major flicker problem drawing a very simple gif file. This
applet seems so simple - what am I doing wrong? Do I have to use a panel
or a canvas to draw to? It also takes a long time to display.

If I use the NoFlickerApplet from the net(mkgray), it doesn't flicker but
it still takes a long time to display the image. This applet draws the
image off screen first.

Here is my code:

import java.awt.*;
import java.applet.*;
import java.awt.image.*;
import sun.awt.image.URLImageSource;

public class MapTest extends Applet {

private Image joe = null;

public void init() {
joe = getImage(getDocumentBase(), "world.gif");
}

public void paint(Graphics g) {
if (joe != null) {
g.drawImage(joe, 0, 0, 708, 386, this);
}

}
}

=========================================================================
Brian Elliott | 310-948-7038
Northrop Grumman Corp. |
bell...@world.nad.northrop.com |
=========================================================================

-
This message was sent to the java-interest mailing list
Info: send 'help' to java-inter...@java.sun.com

[s...@jersey.uoregon.edu]

In article
<Pine.SUN.3.91.95111...@15553-news.world.nad.northrop.com>

bell...@world.nad.northrop.com ("Brian D. Elliott") writes:

I am having a major flicker problem drawing a very simple gif
file. This applet seems so simple - what am I doing wrong? Do I
have to use a panel or a canvas to draw to? It also takes a long
time to display.

If I use the NoFlickerApplet from the net(mkgray), it doesn't
flicker but it still takes a long time to display the image. This
applet draws the image off screen first.

<code deleted>

The applet you posted does not draw the image offscreen first, but
should draw the image directly in the applet window. Make sure you
have set the WIDTH and HEIGHT variables correctly in your <APPLET>
tag.

Please be more precise as to the specific problems you are having and
mention which OS and which viewer (Netscape or appletviewer) you are
using.

--- SER
--
Sean Russell \ It's OK to judge a book by its cover,
s...@cs.uoregon.edu \ as long as you understand that most of
http://zebu.uoregon.edu/~ser ) the cover artists
Finger Me for PGP Key / have never read the book.
NeXTMail Welcome!!! /

[Alexander Bottema]

> I am having a major flicker problem drawing a very simple gif
> file. This applet seems so simple - what am I doing wrong? Do I have
> to use a panel or a canvas to draw to? It also takes a long time to
> display.
>

> public void paint(Graphics g) {
> if (joe != null) {
> g.drawImage(joe, 0, 0, 708, 386, this);

---------

Try to avoid to pass the size of the image explicitly.
g.drawImage(joe, 0, 0, this); should do.

However, I myself have still another problem:
How do I copy rectangular subareas _across_ various images?
There is a primitive call that allows me copy within an image
but not across. Will such a primitive be available, or is there
a reason not to implement it?

/ Alexander

--
Alexander Jean-Claude Bottema (Ph.D. student) | Linux is the ONLY OS I
(Email: al...@csd.uu.se) | use on my PC.
University of Uppsala <stdclaim> |
http://www.csd.uu.se/~alexb/ |

[Jim Graham]

al...@csd.uu.se (Alexander Bottema) writes:
> How do I copy rectangular subareas _across_ various images?
> There is a primitive call that allows me copy within an image
> but not across. Will such a primitive be available, or is there
> a reason not to implement it?

In general the philosophy was that Image objects are static objects
that you do things with, rather than do things to. Offscreen images
are the exception, you both render to them and then render from them.

If you want to compose a new image from pieces and arrangements of
existing images, you can use an offscreen image (createImage(w,h))
and compose your composite image there, and then use that as an
image itself.

...jim

[Alexander Bottema]

> In general the philosophy was that Image objects are static objects
> that you do things with, rather than do things to. Offscreen images
> are the exception, you both render to them and then render from them.
>
> If you want to compose a new image from pieces and arrangements of
> existing images, you can use an offscreen image (createImage(w,h))
> and compose your composite image there, and then use that as an
> image itself.

Thanks for your answer, but unfortunately I already know this and it
will not solve my problem. You see, for reasons I have a big offscreen
image that I use as a double buffer. Everything I draw, I'll draw on
this offscreen image. Then, on occasions, I would like to update the
actual screen image with _partials_ of this offscreen image. Updating
the entire screen is fast in the appletviewer, but outrageously slow
in Netscape beta (name me one reason why I don't like netscape beta
:)). So, a primitive function like copyArea() but with the
functionality to copy subareas across images would solve my problem.

I saw (according to the documentation) that you have implemented the
java.awt.image classes. Actually, you can use them to fetch a subarea
from a given image albeit it will be very inefficient, i.e. you have
to traverse all the pixels even though you only need a few of them.

[Alexander Bottema]

> i'm not shure, but perhaps this works... Copy from image i1 to point
> x,y in image i2:
>
> i2.getGraphics().drawImage(i1, x, y, this);

This operation will draw the _entire_ image of i1 onto i2. I'd like to
draw a _subarea_ from i1 onto i2.

[Jill Shermer]

Hi,

I followed your suggestion as well, and am happy with the results.
Thank you!
If you don't mind another question, can you respond to the following:

I have a top-left black border which is drawn at the beginning
of each iteration of my image loop; it disappears after the 1st
image is drawn. Specifically, the border runs along the top and
left side of the area where my first image is to be drawn.
The border is not in my gif images. I would like
to get rid of it. My images are drawn at the same location, without
any offset. When my system load is heavy, I notice this top-left border
is drawn before any image is draw; the left portion is less about
10 pixels wide and the top portion is about 5 pixels in height.

This border appears in both the appletviewer and in Netscape 2.0 beta.

Any suggestions on how to solve this would be appreciated!

Thanks in advance,

-Jill

> Subject: Re: Simple Draw Image
> Mime-Version: 1.0
> X-Info: To unsubscribe, send 'unsubscribe' to java-inter...@java.sun.com
>
> Overload update do that it does not clear the applet first:
>
> public void update(Graphics g) {
> paint(g);
> }
>
> That should do it.
>
> Aleph One / ale...@dfw.net
> http://underground.org/
> KeyID 1024/948FD6B5
> Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01

[Jim Graham]

Hi Jill,

> Hmmm, I have figured out, by resizing my appletviewer window to
> cover my root window, that the first image in my image loop is drawn to
> a very large scale before my image loop is drawn. That is why I
> am seeing this unexpected top-left border interferring with my expected image
> loop. How do I turn this off? Any clues?

There is nothing inherent in the image drawing code that draws your
image to a very large scale for you, you have to be doing that yourself.

Without seeing your code, it sounds as if you are using the scaling
version of drawImage (drawImage(img, x, y, w, h, this)) with improperly
initialized variables for the width and height parameters. If you don't
want scaling, then just use the regular method (drawImage(img, x, y, this)),
otherwise, make sure that the width and height you are requesting are
the width and height you really want (i.e. the variables you are using
have been properly initialized with the dimensions you want).

...jim

[Jill Shermer]

Hmmm, I have figured out, by resizing my appletviewer window to
cover my root window, that the first image in my image loop is drawn to
a very large scale before my image loop is drawn. That is why I
am seeing this unexpected top-left border interferring with my expected image
loop. How do I turn this off? Any clues?

-Jill
jshe...@basisinc.com

----- Begin Included Message -----

From jshermer Tue Nov 21 11:32:39 1995
To: ale...@dfw.net

Subject: Re: Simple Draw Image

Cc: java-i...@java.sun.com

Hi,

I followed your suggestion as well, and am happy with the results.
Thank you!
If you don't mind another question, can you respond to the following:

I have a top-left black border which is drawn at the beginning
of each iteration of my image loop; it disappears after the 1st
image is drawn. Specifically, the border runs along the top and
left side of the area where my first image is to be drawn.
The border is not in my gif images. I would like
to get rid of it. My images are drawn at the same location, without
any offset. When my system load is heavy, I notice this top-left border
is drawn before any image is draw; the left portion is less about
10 pixels wide and the top portion is about 5 pixels in height.

This border appears in both the appletviewer and in Netscape 2.0 beta.

Any suggestions on how to solve this would be appreciated!

Thanks in advance,

-Jill

----- End Included Message -----

[Alexander Kandzior]

> However, I myself have still another problem:

> How do I copy rectangular subareas _across_ various images?
> There is a primitive call that allows me copy within an image
> but not across. Will such a primitive be available, or is there
> a reason not to implement it?

Hmm..

i'm not shure, but perhaps this works...
Copy from image i1 to point x,y in image i2:

i2.getGraphics().drawImage(i1, x, y, this);

...or something.
ALEX.

[Alexander Kandzior]

[Jill Shermer]

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 43

HI,

See my attached file which uses the regular method
drawImage(img, width, height, this).

Thanks,

-Jill

----- Begin Included Message -----

From fl...@bendenweyr.Eng.Sun.COM Tue Nov 21 13:54 PST 1995
Date: Tue, 21 Nov 1995 13:54:27 -0800
From: fl...@bendenweyr.Eng.Sun.COM (Jim Graham)
To: ale...@dfw.net, jshe...@BASISinc.com

Subject: Re: Simple Draw Image

Cc: java-i...@java.Eng.Sun.COM

Hi Jill,

> Hmmm, I have figured out, by resizing my appletviewer window to
> cover my root window, that the first image in my image loop is drawn to
> a very large scale before my image loop is drawn. That is why I
> am seeing this unexpected top-left border interferring with my expected image
> loop. How do I turn this off? Any clues?

There is nothing inherent in the image drawing code that draws your

image to a very large scale for you, you have to be doing that yourself.

Without seeing your code, it sounds as if you are using the scaling
version of drawImage (drawImage(img, x, y, w, h, this)) with improperly
initialized variables for the width and height parameters. If you don't
want scaling, then just use the regular method (drawImage(img, x, y, this)),
otherwise, make sure that the width and height you are requesting are
the width and height you really want (i.e. the variables you are using
have been properly initialized with the dimensions you want).

...jim

----- End Included Message -----

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: WizardItem.java
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 182

/*
* @(#)Wizard.java
*
* Copyright (c) 1994-1995 Sun Microsystems, Inc. All Rights Reserved.
*
* Permission to use, copy, modify, and distribute this software
* and its documentation for NON-COMMERCIAL or COMMERCIAL purposes and
* without fee is hereby granted.
* Please refer to the file http://java.sun.com/copy_trademarks.html
* for further important copyright and trademark information and to
* http://java.sun.com/licensing.html for further important licensing
* information for the Java (tm) Technology.
*
* SUN MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF
* THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
* TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
* PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR
* ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR
* DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
*
* THIS SOFTWARE IS NOT DESIGNED OR INTENDED FOR USE OR RESALE AS ON-LINE
* CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE
* PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT
* NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE
* SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF THE
* SOFTWARE COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE
* PHYSICAL OR ENVIRONMENTAL DAMAGE ("HIGH RISK ACTIVITIES"). SUN
* SPECIFICALLY DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY OF FITNESS FOR
* HIGH RISK ACTIVITIES.
*/

import java.io.InputStream;
import java.applet.Applet;
import java.awt.*;
import java.net.*;

/**
* A simple Item class to play an image loop. The "img" tag parameter
* indicates what image loop to play.
*
* @author James Gosling
* @version 1.17, 31 Jan 1995
*/
public
class WizardItem extends Applet implements Runnable {
/**
* The current loop slot.
*/
int loopslot = 0;
/**
* The directory or URL from which the images are loaded
*/
String dir;

/**
* The thread animating the images.
*/
Thread kicker = null;

/**
* The length of the pause between revs.
*/
int pause;
int speed;
int nimgs;

/**
* The images.
*/
Image imgs[];

/**
* The offscreen image.
*/
Image im;

/**
* The offscreen graphics context
*/
Graphics offscreen;

int maxWidth;
int maxHeight;

/**
* Initialize the applet. Get attributes.
*/
public void init() {
//System.out.println("WizardItem.init");
String at = getParameter("img");
dir = (at != null) ? at : "images";
at = getParameter("pause");
pause = (at != null) ? Integer.valueOf(at).intValue() : 3900;
at = getParameter("speed");
speed = (at != null) ? (1000 / Integer.valueOf(at).intValue()) : 100;
at = getParameter("nimgs");
nimgs = (at != null) ? Integer.valueOf(at).intValue() : 9;
at = getParameter("maxwidth");
maxWidth = (at != null) ? Integer.valueOf(at).intValue() : 102;
at = getParameter("maxheight");
maxHeight = (at != null) ? Integer.valueOf(at).intValue() : 128;

}

/**
* Run the image loop. This methods is called by class Thread.
* @see java.lang.Thread
*/
public void run() {
//System.out.println("WizardItem.run");
Thread.currentThread().setPriority(Thread.NORM_PRIORITY-1);
imgs = new Image[nimgs];
for (int i = 1; i < nimgs; i++) {
imgs[i] = getImage(getDocumentBase(),dir + "/Wizard" + i + ".gif");
}

Dimension d = size();
if (nimgs > 1) {
while (kicker != null) {
//System.out.println("frame = " + loopslot);
if (++loopslot >= nimgs) {
loopslot = 0;
}
repaint();
try {
Thread.sleep(speed + ((loopslot == nimgs - 1) ? pause : 0));
} catch (InterruptedException e) {
break;
}
}
}
}

public boolean imageUpdate(Image img, int flags,
int x, int y, int w, int h) {
if ((flags & (SOMEBITS|FRAMEBITS|ALLBITS)) != 0) {
if ((imgs != null) && (loopslot < nimgs)
&& (imgs[loopslot] == img)) {
repaint(100);
}
}
return (flags & (ALLBITS|ERROR)) == 0;
}

/**
* Paint the current frame.
*/
public void paint(Graphics g) {
//System.out.println("paint");
if ((imgs != null) && (loopslot < nimgs) && (imgs[loopslot] != null)) {
// im = createImage(102, 128);
// offscreen = im.getGraphics();
// offscreen.setColor(Color.lightGray);
// offscreen.fillRect(0,0,102,128);
// offscreen.drawImage(imgs[loopslot], 0, 0, this);
// g.drawImage(im, 0, 0, this);
g.drawImage(imgs[loopslot], 0, 0, this);
}
}

/**
* Start the applet by forking an animation thread.
*/
public void start() {
if (kicker == null) {
kicker = new Thread(this);
kicker.start();
}
}

/**
* Stop the applet. The thread will exit because kicker is set to null.
*/
public void stop() {
if (kicker != null) {
kicker.stop();
kicker = null;

[Garth Allen Dickie]

fl...@bendenweyr.Eng.Sun.COM (Jim Graham) writes:
>Hi Jill,

>> Hmmm, I have figured out, by resizing my appletviewer window to
>> cover my root window, that the first image in my image loop is drawn to
>> a very large scale before my image loop is drawn. That is why I
>> am seeing this unexpected top-left border interferring with my expected image
>> loop. How do I turn this off? Any clues?

>There is nothing inherent in the image drawing code that draws your
>image to a very large scale for you, you have to be doing that yourself.

>Without seeing your code, it sounds as if you are using the scaling
>version of drawImage (drawImage(img, x, y, w, h, this)) with improperly
>initialized variables for the width and height parameters. If you don't
>want scaling, then just use the regular method (drawImage(img, x, y, this)),
>otherwise, make sure that the width and height you are requesting are
>the width and height you really want (i.e. the variables you are using
>have been properly initialized with the dimensions you want).

I had some strange effects like this when I called drawImage( img, x, y, null ).
Make sure that you are passing an ImageObserver as the last parameter;
almost always, you want to just pass the Component that is being drawn.

Sort of related idea:

For offscreen drawing, you may be running in a separate thread and want
to wait for drawing to complete before proceeding. For example, it would
be nice to be able to just write:

public void updateOffscreen( Image dest ) {
Graphics g = dest.getGraphics( );
g.drawImage( background, 0, 0 ); // incorrect - no ImageObserver
g.drawImage( overlay, 0, 0 ); // incorrect - no ImageObserver
g.dispose( );
}

To get this effect, I have tried the following synchronization class:

public class ImageNotifier implements ImageObserver {
private boolean ready = false;

public synchronized void get( ) {
while( ! ready ) try wait( ); catch( InterruptedException e ) ;
ready = false;
}

public synchronized void put( ) {
ready = true;
notify( );
}

public boolean imageUpdate( Image image, int flags, int x, int y, int width, int height) {
boolean done = flags & ImageObserver.ALLBITS != 0;
if( done ) put( );
return ! done;
}
}

then the drawing calls become:

public void updateOffscreen( Image dest ) {
Graphics g = dest.getGraphics( );
ImageNotifier notify = new ImageNotifier( );

while( ! g.drawImage( background, 0, 0, notify ))
notify.get( );
while( ! g.drawImage( overlay, 0, 0, notify ))
notify.get( );

g.dispose( );
}

Of course, you only want to do this sort of thing in a thread other
than the main thread, so the the user interface can keep running.

Please let me know if there are better ways to do this sort of thing,
by posting or by email to dic...@win.tue.nl. Thanks!

Regards,
Garth

[Jim Graham]

al...@csd.uu.se (Alexander Bottema) writes:
> Then, on occasions, I would like to update the
> actual screen image with _partials_ of this offscreen image.

> So, a primitive function like copyArea() but with the
> functionality to copy subareas across images would solve my problem.

If you want to draw part of an image on the screen, use clipping:

// Draw (srcX, srcY, W, H) subrectangle of image at
// coordinates (destX, destY) of the Component.
Graphics subg = g.create(destX, destY, W, H);
subg.drawImage(img, -srcX, -srcY, this);

(I think, I might have gotten the coordinates wrong since g.create
does an implicit translate...)

...jim

[Alexander Bottema]

> If you want to draw part of an image on the screen, use clipping:
>
> // Draw (srcX, srcY, W, H) subrectangle of image at
> // coordinates (destX, destY) of the Component.
> Graphics subg = g.create(destX, destY, W, H);
> subg.drawImage(img, -srcX, -srcY, this);
>
> (I think, I might have gotten the coordinates wrong since g.create
> does an implicit translate...)

Yes, that will probably work and I guess it will be efficient enough.
Of course you can use the above procedure on any images, since
the graphic context is avaiable via the image (getGraphics()).

Thanks, but I already solved my problem. Actually, it was never a
problem in the first place, since drawing the entire image was fast
enough. However, it seems that the event handler is starved by the
intense graphic drawing. I don't want to make a Thread.sleep()
(and Thread.yield() didn't help, why?) since that would cause a
performance degradation. Furthermore, thread priorities seem not
to work either. My next question is: Is there any way to explicitly
call the event handler to process the next event in the event queue
for a given canvas? Or is there another way to ensure that the event
handler is not starved by other threads?

Thanks again for answering my post.

-- Alexander

[Jim Graham]

al...@csd.uu.se (Alexander Bottema) writes:
> Of course you can use the above procedure on any images, since
> the graphic context is avaiable via the image (getGraphics()).

Please note that as the documentation states, Image.getGraphics only
works for offscreen images. You can't "draw to" any other type of
image.

> Thanks, but I already solved my problem. Actually, it was never a
> problem in the first place, since drawing the entire image was fast
> enough. However, it seems that the event handler is starved by the
> intense graphic drawing. I don't want to make a Thread.sleep()
> (and Thread.yield() didn't help, why?) since that would cause a
> performance degradation. Furthermore, thread priorities seem not
> to work either. My next question is: Is there any way to explicitly
> call the event handler to process the next event in the event queue
> for a given canvas? Or is there another way to ensure that the event
> handler is not starved by other threads?

You aren't, by any chance, going into a loop in your "paint" or "update"
method, are you? paint() and update() should draw whatever needs to
be drawn *right now* and return as soon as possible. You should use
a separate thread to drive your animations, spawned specifically for
that purpose, and it should update your instance variables for the
state for each new frame of animation and then call "repaint()"
followed by some minimal sleep (such as about 100ms for most animations
that applets are performing) to give the system time to call your update()
method and have it draw one frame of the animation and return...

...jim

[Alexander Bottema]

> Please note that as the documentation states, Image.getGraphics only
> works for offscreen images. You can't "draw to" any other type of
> image.

Ok, no problem. However, I implemented the "partial update" idea
using the clipping method that you provided and it works much better
(i.e. everything is much faster). So thanks again, your recommendation
was necessary after all.

> You aren't, by any chance, going into a loop in your "paint" or
> "update" method, are you? paint() and update() should draw whatever
> needs to be drawn *right now* and return as soon as possible. You
> should use a separate thread to drive your animations, spawned
> specifically for that purpose, and it should update your instance
> variables for the state for each new frame of animation and then call
> "repaint()" followed by some minimal sleep (such as about 100ms for
> most animations that applets are performing) to give the system time
> to call your update() method and have it draw one frame of the
> animation and return...

No, I don't have a loop in the paint and update methods. If I put
a thread sleep for ten milliseconds everything works pretty good
(e.g. events from the keyboard are "instantly" treated during
animation. But ten milliseconds gives a performance degradation
that is not acceptable. Five milliseconds gives a performance that
is nearly acceptable. However, I think I'll solve this problem in
one way or another. If my hobby project turns out to be successful
you can study the result for yourself on my new forthcoming home
page. Though I still have the problem that Netscape Beta behaves
very different from the appletviewer regarding performance issues.
Sometimes Netscape Beta is extremly slow. Well it ain't a Sun
product... :) Say, is there a Hotjava Beta being developed?

/ Alexander

[Jim Graham]

al...@csd.uu.se (Alexander Bottema) writes:
>No, I don't have a loop in the paint and update methods. If I put
>a thread sleep for ten milliseconds everything works pretty good
>(e.g. events from the keyboard are "instantly" treated during
>animation. But ten milliseconds gives a performance degradation
>that is not acceptable. Five milliseconds gives a performance that
>is nearly acceptable.

If I understand you right you are doing an animation at 100 frames
per second and you aren't happy with the performance? Your monitor
is only refreshing at about 66-76 frames per second so you shouldn't
even be able to see 100 frames per second (i.e. some of them will
be lost in the vertical refresh of the monitor). Or am I mistaken
in assuming that you are talking about the delay for a graphical
animation loop?

...jim