Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #2020 > unrolled thread

Problem with loaded image

Back to article view | Back to comp.lang.java.gui

Contents

  Problem with loaded image "Daniel Kraft" <daniel.kraft@THRWHITE.remove-dii-this> - 2011-04-27 15:36 +0000
    Re: Problem with loaded i "Roedy Green" <roedy.green@THRWHITE.remove-dii-this> - 2011-04-27 15:36 +0000
    Re: Problem with loaded i "A. Bolmarcich" <a..bolmarcich@THRWHITE.remove-dii-this> - 2011-04-27 15:36 +0000
      Re: Problem with loaded i "Daniel Kraft" <daniel.kraft@THRWHITE.remove-dii-this> - 2011-04-27 15:36 +0000
        Re: Problem with loaded i "A. Bolmarcich" <a..bolmarcich@THRWHITE.remove-dii-this> - 2011-04-27 15:36 +0000
          Re: Problem with loaded i "Daniel Kraft" <daniel.kraft@THRWHITE.remove-dii-this> - 2011-04-27 15:36 +0000

#2020 — Problem with loaded image

  To: comp.lang.java.gui
Hi all,

I've run into a rather strange problem, at least for me.  I've got an 
AWT Frame containing a Canvas at the center of a BorderLayout which an 
Image is painted on.

This Canvas returns the Image's size as preferred size, so on pack()-ing 
the Frame the Image exactly fits in to the Canvas.  This works so far.

However, during runtime the image gets changed, thus also the preferred 
size changes (becomes larger).  After this, I call pack() on the Frame 
again, and it resizes accordingly.  But in spite, the image is drawn 
only in the region of its old size, i.e., the new bigger part is gray 
and the image clipped (I'm calling repaint() after the pack() but that 
seems not to help).

But if I force a repaint by hiding and showing the window through my 
window manager, the image gets drawn completely.

I really have no clue about what the problem could be -- my only 
suspicion is this one:  I use a MediaTracker to load the image so I can 
query for its size; this MediaTracker is initialized with my Canvas as 
ImageObserver when it still has its old size.  Can this cause any 
problem, as only that part of the image is loaded or something like 
that?  It sounds strange to me, but is really the only possible reason 
coming to my mind...

I'm using JDK 1.5.0_06 on GNU/Linux.  If anyone is interested in the 
sources, they can be browsed at
http://minigolf.svn.sourceforge.net/viewvc/minigolf/trunk/src/
The Canvas-component talked about is
net.sourceforge.minigolf.visualizer.Visualizer

Many thanks,
Daniel

-- 
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#2022 — Re: Problem with loaded i

  To: comp.lang.java.gui
On Thu, 12 Jul 2007 17:46:30 +0000, Daniel Kraft <d@domob.eu> wrote,
quoted or indirectly quoted someone who said :

>the new bigger part is gray 
>and the image clipped (I'm calling repaint() after the pack() but that 
>seems not to help).
Put in some debug code in the various getXXXSize methods to see what
you are returning.  You want to override all of them in your Canvas to
return a consistent value.  

See http://mindprod.com/jgloss/addnotify.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#2027 — Re: Problem with loaded i

  To: comp.lang.java.gui
On 2007-07-12, Daniel Kraft <d@domob.eu> wrote:
> Hi all,
>
> I've run into a rather strange problem, at least for me.  I've got an 
> AWT Frame containing a Canvas at the center of a BorderLayout which an 
> Image is painted on.
>
> This Canvas returns the Image's size as preferred size, so on pack()-ing 
> the Frame the Image exactly fits in to the Canvas.  This works so far.
>
> However, during runtime the image gets changed, thus also the preferred 
> size changes (becomes larger).  After this, I call pack() on the Frame 
> again, and it resizes accordingly.  But in spite, the image is drawn 
> only in the region of its old size, i.e., the new bigger part is gray 
> and the image clipped (I'm calling repaint() after the pack() but that 
> seems not to help).
>
> But if I force a repaint by hiding and showing the window through my 
> window manager, the image gets drawn completely.
>
> I really have no clue about what the problem could be -- my only 
> suspicion is this one:  I use a MediaTracker to load the image so I can 
> query for its size; this MediaTracker is initialized with my Canvas as 
> ImageObserver when it still has its old size.  Can this cause any 
> problem, as only that part of the image is loaded or something like 
> that?  It sounds strange to me, but is really the only possible reason 
> coming to my mind...

You should also be suspicious about what is done differently by the
update and paint methods of the extension of Canvas.  You are likely
seeing different redrawing results from pack() and hiding-and-showing
because one ends up invoking update while the other ends up invoking
paint.  See

http://java.sun.com/products/jfc/tsc/articles/painting/index.html#awt

for a description of "Painting in the AWT".

> I'm using JDK 1.5.0_06 on GNU/Linux.  If anyone is interested in the 
> sources, they can be browsed at
> http://minigolf.svn.sourceforge.net/viewvc/minigolf/trunk/src/
> The Canvas-component talked about is
> net.sourceforge.minigolf.visualizer.Visualizer

Based on taking a look at the source

- the update method draws to an Image object (the variable offscreen)
  and draws the image to the Graphics argument of the update method

- the Image object is created only once, although you change the
  size of the image to be drawn the update method draws to the size
  of the original image

You should set the variable offscreen to null when the size of the
images changes so the update method will create a new one with the
correct size.  Because the update method is the only place where
the variable offscreen is used, you may want to eliminate it and
the definition of the update method in your extension of Canvas.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#2035 — Re: Problem with loaded i

  To: comp.lang.java.gui
>> I'm using JDK 1.5.0_06 on GNU/Linux.  If anyone is interested in the 
>> sources, they can be browsed at
>> http://minigolf.svn.sourceforge.net/viewvc/minigolf/trunk/src/
>> The Canvas-component talked about is
>> net.sourceforge.minigolf.visualizer.Visualizer
> 
> Based on taking a look at the source
> 
> - the update method draws to an Image object (the variable offscreen)
>   and draws the image to the Graphics argument of the update method
> 
> - the Image object is created only once, although you change the
>   size of the image to be drawn the update method draws to the size
>   of the original image

Thank you very much, that solved my very problem... I'm sorry for this 
stupid mistake -- however, why was the full image painted when 
hiding/showing the window although the offscreen-image was not resized?

Was this simply "by chance" or is there a stronger reason why that happend?

Yours,
Daniel

-- 
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#2037 — Re: Problem with loaded i

  To: comp.lang.java.gui
On 2007-07-13, Daniel Kraft <d@domob.eu> wrote:
[snip]
> Thank you very much, that solved my very problem... I'm sorry for this 
> stupid mistake -- however, why was the full image painted when 
> hiding/showing the window although the offscreen-image was not resized?
>
> Was this simply "by chance" or is there a stronger reason why that happend?

You can learn the answers these questions by reading another part of my
previous followup that you did not quote in your reply.  Here is that
part again:

  You are likely seeing different redrawing results from pack() and
  hiding-and-showing because one ends up invoking update while the other
  ends up invoking paint.  See
                                                                                
  http://java.sun.com/products/jfc/tsc/articles/painting/index.html#awt
                                                                                
  for a description of "Painting in the AWT".

Over-simplifying:

- When a Java program executes repaint (either directly in code you write
  or in the implementation of standard java methods, such as pack) the
  update method will be called.  Your update method clipped to the size
  of the original image.

- When the windowing system of the computer on which a Java program is
  running determines that a window needs to be repainted, the paint method
  will be called.  Your paint method did not clip to the size of the
  original image.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#2047 — Re: Problem with loaded i

  To: comp.lang.java.gui
>> Thank you very much, that solved my very problem... I'm sorry for this 
>> stupid mistake -- however, why was the full image painted when 
>> hiding/showing the window although the offscreen-image was not resized?
>>
>> Was this simply "by chance" or is there a stronger reason why that happend?
> 
> You can learn the answers these questions by reading another part of my
> previous followup that you did not quote in your reply.  Here is that
> part again:
> 
>   You are likely seeing different redrawing results from pack() and
>   hiding-and-showing because one ends up invoking update while the other
>   ends up invoking paint.  See
>                                                                                 
>   http://java.sun.com/products/jfc/tsc/articles/painting/index.html#awt
>                                                                                 
>   for a description of "Painting in the AWT".
> 
> Over-simplifying:
> 
> - When a Java program executes repaint (either directly in code you write
>   or in the implementation of standard java methods, such as pack) the
>   update method will be called.  Your update method clipped to the size
>   of the original image.
> 
> - When the windowing system of the computer on which a Java program is
>   running determines that a window needs to be repainted, the paint method
>   will be called.  Your paint method did not clip to the size of the
>   original image.

Oh, I see -- up to now I thought repainting would *always* be done via 
update, no matter if I called repaint() manually of the window system 
determined that a repaint was needed.

Once more, thank you!
Daniel

-- 
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.gui

csiph-web