Graphics.drawImage function not working, please help.

  • Follow


Hi,
I'm having a problem with drawImage.

What I'm doing is making a simple class that is extends a Panel (did it 
with Canvas with same result) and I call this class Picture.
An Image object can be passed into the Picture object and then on paint 
the Picture object will draw the Image.

So, the problem is that the painting behavior is weird...
It will paint fine, then if you drag the applet so the Picture gui object 
goes off the screen and then you drag it back on (causing redrawing), it 
only seems to paint on the first paint event it receives... and 
successive draws don't draw anything!

Now, if you again bring the Picture gui object FULLY off screen and then 
back on it will again do the same thing (painting the first paint event), 
so it seems to work for a full object paint, but not when only part of it 
needs to paint.

Note that I've done testing to ensure the paint events are being 
sent/received (they are), and that the Image is valid (it is), and that 
drawImage method is returning true (it is).
Also Note that a drawString call in the same place as the drawImage call 
works fine.

Finally, if I stretch the Image 
ie) drawImage(img, 0, 0, 90, 90, obs) instead of
    drawImage(img, 0, 0, 100, 100, obs)... assuming the image is 100x100
then it works fine (except that the image is stretched/squished)???

So, why would this behavior happen?
Hopefully I explained it well enough...

Picture class code follows:

-----------------------------------------------------------

package MyPackage;

import java.awt.Panel;
import java.awt.MediaTracker;
import java.awt.Image;
import java.awt.Graphics;
import java.lang.InterruptedException;

public class Picture extends Panel
{
	private MediaTracker tracker = null;
	private Image image;

	public Picture(Image img)
	{
		tracker = new MediaTracker(this);
		setPicture(img);
	}

	public void setPicture(Image img)
	{
		image = img;
		if(img != null)
		{
			tracker.addImage(img, 0);
			tracker.checkID(0, true);
		}
		repaint();
	}

	public void paint(Graphics g)
	{
    	    	System.out.println("Picture Paint - Start");
		try
		{
			if(!tracker.checkID(0))
			{
				tracker.waitForID(0);
			}
			
			if(!tracker.isErrorID(0))
			{
				if(g.drawImage(image, 0, 0, this))
    	    	    	    	    	System.out.println("Draw=T");
    	    	    	    	else
    	    	    	    	    	System.out.println("Drawn=F");
			}
		}
		catch(InterruptedException ex)
		{
			System.out.println("Picture Paint - Int.Ex.");
		}

		super.paint(g);
	}
}

-----------------------------------------------------------



Thanks for any and all help.
0
Reply Me 6/17/2005 9:32:26 PM

On Fri, 17 Jun 2005 21:32:26 GMT, Me wrote:

> I'm having a problem with drawImage.

You'll get more people willing to help if you post an SSCCE..
<http://www.physci.org/codes/sscce.jsp>

OTOH..

>	public void paint(Graphics g)

(please replace tabs with 2 or 3 spaces before posting)

>	{
>    	    	System.out.println("Picture Paint - Start");
......
		super.paint(g);
>	}

...that is an odd place to be making a call to super.paint(Graphics).
It would, as I understand, be interfering with the paint process.

Note - Follow-Ups set to comp.lang.gui only.

-- 
Andrew Thompson
http://www.PhySci.org/codes/  Web & IT Help
http://www.PhySci.org/  Open-source software suite
http://www.1point1C.org/  Science & Technology
http://www.LensEscapes.com/  Images that escape the mundane
0
Reply Andrew 6/17/2005 10:29:26 PM


So not sure what was wrong... If I forced the clip region full size on 
each paint then it would work, but the origianl clip region values seemed 
like they should be fine... anyway, forcing the values is no good.

So I continued to try and figure stuff out... I noticed that the problem 
only happens in Java 1.5 (I tested with 1.4.1 & 1.4.2 and they were 
fine), also using the Applet Viewer (v1.5) also works fine, so its just 
the Java 1.5 browser plugin (tested with IE & Firefox).

I realized that I was extending Panel rather than JPanel, (and since most 
my stuff is in swing anyway) I decided to change it to JPanel instead and 
now it works (but in JPanel the super.paint cant be called as I had it, I 
will instead need to call paintComponents I guess).

So in the end it is now working fine for me... BUT that doesn't solve the 
problem that I have found, ie. my diagnosis is that 1.5 has introduced 
something in Component (Panel inherits paint from it) that causes this 
problem. I suppose with JPanel the underlying JContainer's paint is fine, 
even though the same Component class is inherited from (via Container), 
but I don't belive it inherits paint directly.

Anyway... not sure if this is a desired or known and ignored behavior or 
if its a bug that needs fixing...




Me <me@notreal.tld> wrote in news:KjHse.69010$9A2.3420@edtnps89:

[EDITED]

> Hi,
> I'm having a problem with drawImage.
> 
> So, the problem is that the painting behavior is weird...
> ...Picture gui object goes off the screen and then you drag it
> back on... it only seems to paint on the first paint...
> ...and successive draws don't draw anything!
> 
> So, why would this behavior happen?
>
> Thanks for any and all help.

0
Reply Me 6/20/2005 7:02:12 PM

As for the super.paint (as I alluded to in my first follow-up post) it 
didn't create problems (since I was inheriting from Panel), not sure if 
this is another bug or standard behavior... but anyway, when I changed to 
JPanel, yes then super.paint did create an issue, and I dealt with that.

As for SSCCE, I appreciate the setting and enforcement of standards and 
working practices such as this, but in this scenario I felt that the 
problem was conceptually quite simple and adding a bunch of extra code 
simply to create an applet/form/etc. would simply beef up the post and 
make it more difficult to read and understand without much if any real 
benefit.



PS.
I have seen some of your other responses to posts, and it is good to 
govern conduct and standards in an environment like a newsgroup; however, 
I do find that your tone is sometimes hostile and unhelpful. In 
comparison your response to my post was atleast cordial.
Although I do not presume to know your responsibilities and situation, I 
would suggest a less anal, and more constructive and sympathetic 
approach.

As I said I do not mean to be presumptious, or hostile myself, but I 
found the above needed to be said.


EOM







Andrew Thompson <SeeMySites@www.invalid> wrote in news:b6q84mzxi4e5
$.1qu7cx0ehkbnj$.dlg@40tude.net:

> On Fri, 17 Jun 2005 21:32:26 GMT, Me wrote:
> 
>> I'm having a problem with drawImage.
> 
> You'll get more people willing to help if you post an SSCCE..
> <http://www.physci.org/codes/sscce.jsp>
> 
> OTOH..
> 
>>     public void paint(Graphics g)
> 
> (please replace tabs with 2 or 3 spaces before posting)
> 
>>     {
>>                  System.out.println("Picture Paint - Start");
> .....
>           super.paint(g);
>>     }
> 
> ..that is an odd place to be making a call to super.paint(Graphics).
> It would, as I understand, be interfering with the paint process.
> 
> Note - Follow-Ups set to comp.lang.gui only.
> 

0
Reply Me 6/20/2005 7:21:18 PM

On Mon, 20 Jun 2005 19:21:18 GMT, Me wrote:

> As for the super.paint (as I alluded to in my first follow-up post) it 
> didn't create problems (since I was inheriting from Panel),

That means very little - you were calling super.paint() at the
*end* of your paint() method, so everything you did before that 
was potentially being overwritten by the parent method.

Do you understand that much?

It is hard to say for sure without a complete code example, but
it seems you have achieved a solution largely through good luck.

Quick - buy a lottery ticket.   ;-)

-- 
Andrew Thompson
http://www.PhySci.org/codes/  Web & IT Help
http://www.PhySci.org/  Open-source software suite
http://www.1point1C.org/  Science & Technology
http://www.LensEscapes.com/  Images that escape the mundane
0
Reply Andrew 6/20/2005 7:42:08 PM

Yes I understood perfectly well what you were getting to with your 
super.paint suggestion; however, as I said it doesn't make a difference, 
I could (and did try) removing the super.paint with NO change. Plus if 
super.paint did make a problem, the problem it would make would most 
likely be a full over draw of the component causing NO image to be seen 
ever, which was not the case.

Note that as said, now with JPanel instead of Panel the problem with 
super.paint does happen and it does draw fully over anything that I might 
draw before calling it, and this is the behavior I suspected should 
happen... and when writing my original code I thought it would (evidently 
with Panel it does not though).

As for finding the solution??? I said I tryed using JPanel instead of 
Panel, and it worked fine, I never said I solved the problem.... I did 
NOT solve the problem, and therefore have submitted a bug report to Sun, 
I also mentioned in my other follow up that I am still wondering why this 
behavior is happening.
For the applet I'm writing currently I have a resolution, but NO I did 
not find a solution for the problem.

Furthermore your (below) response illustrates the hostile and unhelpful 
approach you seem to take (as I mentioned in my follow up to your 
original comments), in that other follow up I tryed to be cordial (as I 
called it), but in this one I will respond:

GET THAT BUG OUT OF YOUR ASS, BITCH







Andrew Thompson <SeeMySites@www.invalid> wrote in news:u0dnkg8t33lw
$.1snomwhyiqej4$.dlg@40tude.net:

> On Mon, 20 Jun 2005 19:21:18 GMT, Me wrote:
> 
>> As for the super.paint (as I alluded to in my first follow-up post) it 
>> didn't create problems (since I was inheriting from Panel),
> 
> That means very little - you were calling super.paint() at the
> *end* of your paint() method, so everything you did before that 
> was potentially being overwritten by the parent method.
> 
> Do you understand that much?
> 
> It is hard to say for sure without a complete code example, but
> it seems you have achieved a solution largely through good luck.
> 
> Quick - buy a lottery ticket.   ;-)
> 

0
Reply Me 6/20/2005 9:10:16 PM

Here is an executable version of the source, chopped it down to just what 
is necessary... should run, and should produce the problem.


------------------------------------


package JavaTest;

import java.awt.*;
import javax.swing.*;
import java.net.*;

public class JavaTest extends JApplet
{
	Picture picTest = new Picture();

	public void init()
	{
		try
		{
			URL basepath = getCodeBase();
			picTest.image = getImage(new URL
(basepath+"testpic.gif"));
		}
		catch(MalformedURLException ex){}
		
		picTest.setBounds(new Rectangle(10, 10, 50, 50));
		this.setLayout(null);
		this.add(picTest, null);
	}
	
	public class Picture extends Panel
	{
		public Image image;

		public void paint(Graphics g)
		{
			g.drawImage(image, 0, 0, this);
		}
	}
}

-------------------------------

EOM
0
Reply Me 6/20/2005 9:48:17 PM

On Mon, 20 Jun 2005 21:48:17 GMT, Me wrote:

> public class JavaTest extends JApplet

Change to..

public class JavaTest extends java.applet.Applet
....

There are probably other ways to fix this source, 
but for those, perhaps you had better ask someone 
that you have not just sworn at..  

Note: Follow-ups set to c.l.j.gui.

-- 
Andrew Thompson
http://www.PhySci.org/codes/  Web & IT Help
http://www.PhySci.org/  Open-source software suite
http://www.1point1C.org/  Science & Technology
http://www.LensEscapes.com/  Images that escape the mundane
0
Reply Andrew 6/20/2005 10:06:16 PM

7 Replies
294 Views

(page loaded in 0.056 seconds)

Similiar Articles:













7/24/2012 12:07:26 PM


Reply: