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

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

Drawing problem

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

Contents

  Drawing problem "Robert Sturzenegger" <robert.sturzenegger@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
    Re: Drawing problem "Andrew Thompson" <andrew.thompson@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
      Re: Drawing problem "Robert Sturzenegger" <robert.sturzenegger@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
    Re: Drawing problem "Michael Rauscher" <michael.rauscher@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
      Re: Drawing problem "Robert Sturzenegger" <robert.sturzenegger@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
        Re: Drawing problem "Michael Rauscher" <michael.rauscher@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
          Re: Drawing problem "Knute Johnson" <knute.johnson@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
            Re: Drawing problem "Michael Rauscher" <michael.rauscher@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
              Re: Drawing problem "Knute Johnson" <knute.johnson@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
                Re: Drawing problem "Michael Rauscher" <michael.rauscher@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
                  Re: Drawing problem "Knute Johnson" <knute.johnson@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
                    Re: Drawing problem "Michael Rauscher" <michael.rauscher@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
          Re: Drawing problem "Robert Sturzenegger" <robert.sturzenegger@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000

#1099 — Drawing problem

  To: comp.lang.java.gui
Hello

I would like to draw a graph in a container. Since the calculation of the 
graph may be very time consuming, I would like to watch how the graph builds 
up.
The problem is, that the graph builds up behind the scene and it shows only 
after the calculation is complete.
Can anyone give me a hint, what I have to change to see the graph grow, 
while it is being calculated?

The program below is a simplification of my real program. Instead of a time 
consuming calculation, I'm using a loop with a short sleep in every 
iteration.
The problem however remains the same.

Thanks for your help!
Robert


public class Painter extends JFrame {
    DrawArea m_DrawArea = new DrawArea();
    Painter() {
        setDefaultCloseOperation(EXIT_ON_CLOSE);
        getContentPane().add(m_DrawArea);
        setExtendedState(JFrame.MAXIMIZED_BOTH);
    }
    class DrawArea extends JPanel {
        public void paintComponent(Graphics g) {
            super.paintComponent(g);
            for (int i = 0; i < 200; ++i) {
                g.drawLine(i, i, i - 1, i - 1);
                try { Thread.sleep(50); } catch(Exception e) {}
            }
        }
    }
    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                Painter p = new Painter();
                p.setVisible(true);
            }
        });
    }
}

---
 * 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]

#1100

  To: comp.lang.java.gui
On Mar 4, 12:10 am, "Robert Sturzenegger" <nob...@nowhere.com> wrote:
..
> I would like to draw ... Since the calculation of the
> graph may be very time consuming,
...
> Can anyone give me a hint, what I have to change to see the graph grow,
> while it is being calculated?

Remove the time consuming task from the EDT.

A quick google of relevant terms suggests ..
<http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html>
<http://java.sun.com/docs/books/tutorial/uiswing/concurrency/
index.html>

HTH

Andrew T.

---
 * 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]

#1105

  To: comp.lang.java.gui

"Andrew Thompson" <andrewthommo@gmail.com> wrote in message 
news:1172930808.138941.97390@h3g2000cwc.googlegroups.com...
> On Mar 4, 12:10 am, "Robert Sturzenegger" <nob...@nowhere.com> wrote:
> ..
>> I would like to draw ... Since the calculation of the
>> graph may be very time consuming,
> ...
>> Can anyone give me a hint, what I have to change to see the graph grow,
>> while it is being calculated?
>
> Remove the time consuming task from the EDT.
>
> A quick google of relevant terms suggests ..
> <http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html>
> <http://java.sun.com/docs/books/tutorial/uiswing/concurrency/
> index.html>
>
> HTH
>
> Andrew T.
>

Thanks for your response!

I understand that I should move the calculation of the graph to another 
thread. I have also read the two articles you referred to, but I still don't 
really know how to implement that. The problem is the link between the 
result of the calculation in the other thread and the method paintComponent, 
whose calling is not under my control.

Can you please give me an additional hint?

Thanks, Robert

---
 * 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]

#1104

  To: comp.lang.java.gui
Robert Sturzenegger schrieb:
> Hello
> 
> I would like to draw a graph in a container. Since the calculation of the 
> graph may be very time consuming, I would like to watch how the graph builds 
> up.

If it's just for testing purposes, you could turn off Swing's double 
buffering. Otherwise Andrew Thompson's method is much preferred.


>     public static void main(String[] args) {
>         SwingUtilities.invokeLater(new Runnable() {
>             public void run() {
>                 Painter p = new Painter();

RepaintManager.currentManager(p).setDoubleBufferingEnabled(false);

Bye
Michael

---
 * 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]

#1106

  To: comp.lang.java.gui

"Michael Rauscher" <michlmann@gmx.de> wrote in message 
news:esc7i4$lvv$1@registered.motzarella.org...
> Robert Sturzenegger schrieb:
>> Hello
>>
>> I would like to draw a graph in a container. Since the calculation of the 
>> graph may be very time consuming, I would like to watch how the graph 
>> builds up.
>
> If it's just for testing purposes, you could turn off Swing's double 
> buffering. Otherwise Andrew Thompson's method is much preferred.
>
>
>>     public static void main(String[] args) {
>>         SwingUtilities.invokeLater(new Runnable() {
>>             public void run() {
>>                 Painter p = new Painter();
>
> RepaintManager.currentManager(p).setDoubleBufferingEnabled(false);
>
> Bye
> Michael


Thank you for your response!

I tried this and it really accomplishes what I want. Since you stated, that 
this solution should be for testing purposes only and that Andrew Thompson's 
method would be the preferred one, I also wanted to try his way. However I 
failed .... Details can be found in a response to his suggestion.

Thanks, Robert

---
 * 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]

#1108

  To: comp.lang.java.gui
Robert Sturzenegger wrote:
>>> I would like to draw a graph in a container. Since the calculation of the 
>>> graph may be very time consuming, I would like to watch how the graph 
>>> builds up.

Michael Rauscher wrote:

>> If it's just for testing purposes, you could turn off Swing's double 
>> buffering. Otherwise Andrew Thompson's method is much preferred.

[Andrew Thompson suggested to remove the time consuming task from the EDT].

Robert Sturzenegger wrote:

> I tried this and it really accomplishes what I want. Since you stated, that 
> this solution should be for testing purposes only and that Andrew Thompson's 
> method would be the preferred one, I also wanted to try his way. However I 
> failed .... Details can be found in a response to his suggestion.

The key is to separate the 'current state' of the drawing from the 
drawing process.

E.g. you might want to use a BufferedImage as offscreen image. 
paintComponent simply draws that image on screen.

private BufferedImage img = new BufferedImage(400, 400,
         BufferedImage.TYPE_INT_ARGB);

public void paintComponent( Graphics g ) {
     g.drawImage( img, 0, 0, null );
}

In theory, you could now manipulate the image and call repaint to show 
the result on screen. In practice, this is possible, too. The only thing 
you'd have to care of, is to manipulate the image on the EDT.

So:

private void calculateAndPaint() {
     for ( int x = 0; x < 200; ++x ) {
         final int i = x;
         SwingUtilities.invokeLater( new Runnable() {
             public void run() {
                 Graphics g = img.createGraphics();
                 g.drawLine( i, i, i-1, i-1 );
                 g.dispose();
                 repaint();
             }
         });
         try { Thread.sleep(10); } catch ( InterruptedException e ) {}
     }
}

The last thing one has to do is to let calculateAndPaint be run on a new 
Thread:

public void paint() {
     Thread t = new Thread( new Runnable() {
         public void run() {
             calculateAndPaint();
         }
     });
     t.setPriority( Thread.NORM_PRIORITY );
     t.start();
}

Bye
Michael

---
 * 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]

#1109

  To: comp.lang.java.gui
Michael Rauscher wrote:
> Robert Sturzenegger wrote:
>>>> I would like to draw a graph in a container. Since the calculation 
>>>> of the graph may be very time consuming, I would like to watch how 
>>>> the graph builds up.
> 
> Michael Rauscher wrote:
> 
>>> If it's just for testing purposes, you could turn off Swing's double 
>>> buffering. Otherwise Andrew Thompson's method is much preferred.
> 
> [Andrew Thompson suggested to remove the time consuming task from the EDT].
> 
> Robert Sturzenegger wrote:
> 
>> I tried this and it really accomplishes what I want. Since you stated, 
>> that this solution should be for testing purposes only and that Andrew 
>> Thompson's method would be the preferred one, I also wanted to try his 
>> way. However I failed .... Details can be found in a response to his 
>> suggestion.
> 
> The key is to separate the 'current state' of the drawing from the 
> drawing process.
> 
> E.g. you might want to use a BufferedImage as offscreen image. 
> paintComponent simply draws that image on screen.
> 
> private BufferedImage img = new BufferedImage(400, 400,
>         BufferedImage.TYPE_INT_ARGB);
> 
> public void paintComponent( Graphics g ) {
>     g.drawImage( img, 0, 0, null );
> }
> 
> In theory, you could now manipulate the image and call repaint to show 
> the result on screen. In practice, this is possible, too. The only thing 
> you'd have to care of, is to manipulate the image on the EDT.
> 
> So:
> 
> private void calculateAndPaint() {
>     for ( int x = 0; x < 200; ++x ) {
>         final int i = x;
>         SwingUtilities.invokeLater( new Runnable() {
>             public void run() {
>                 Graphics g = img.createGraphics();
>                 g.drawLine( i, i, i-1, i-1 );
>                 g.dispose();
>                 repaint();
>             }
>         });
>         try { Thread.sleep(10); } catch ( InterruptedException e ) {}
>     }
> }
> 
> The last thing one has to do is to let calculateAndPaint be run on a new 
> Thread:
> 
> public void paint() {
>     Thread t = new Thread( new Runnable() {
>         public void run() {
>             calculateAndPaint();
>         }
>     });
>     t.setPriority( Thread.NORM_PRIORITY );
>     t.start();
> }
> 
> Bye
> Michael

There is no requirement that repaint() or graphics calls be made on the EDT.

I wouldn't use paint() as the name of the method because you might 
interfere with normal painting.

-- 

Knute Johnson
email s/nospam/knute/

---
 * 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]

#1112

  To: comp.lang.java.gui
Knute Johnson wrote:
> Michael Rauscher wrote:
>> private void calculateAndPaint() {
>>     for ( int x = 0; x < 200; ++x ) {
>>         final int i = x;
>>         SwingUtilities.invokeLater( new Runnable() {
>>             public void run() {
>>                 Graphics g = img.createGraphics();
>>                 g.drawLine( i, i, i-1, i-1 );
>>                 g.dispose();
>>                 repaint();
>>             }
>>         });
>>         try { Thread.sleep(10); } catch ( InterruptedException e ) {}
>>     }
>> }
>>
> 
> There is no requirement that repaint() or graphics calls be made on the 
> EDT.

With respect to repaint: you're right, of course.

Do you mean that it's safe to manipulate an image in a non-EDT thread 
while the EDT might draw it?

I was unsure about this, perhaps you can provide some links with 
detailed informations on this subject.

> I wouldn't use paint() as the name of the method because you might 
> interfere with normal painting.

ACK. Call it draw() then.

Bye
Michael

---
 * 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]

#1115

  To: comp.lang.java.gui
Michael Rauscher wrote:
> Knute Johnson wrote:
>> Michael Rauscher wrote:
>> There is no requirement that repaint() or graphics calls be made on 
>> the EDT.
> 
> With respect to repaint: you're right, of course.
> 
> Do you mean that it's safe to manipulate an image in a non-EDT thread 
> while the EDT might draw it?

Yes.

> I was unsure about this, perhaps you can provide some links with 
> detailed informations on this subject.

I don't have any links for you but BufferedImage is not a Swing 
component and therefore won't have any problems being modified outside 
of the EDT.  Also, during a paint operation, the BufferedImage will just 
be copied into the component's buffer and then be blitted to the video. 
  Even if the component was unbuffered all that could possibly happen is 
that as the image is drawn that it would be changing.

-- 

Knute Johnson
email s/nospam/knute/

---
 * 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]

#1121

  To: comp.lang.java.gui
Knute Johnson wrote:
> I don't have any links for you but BufferedImage is not a Swing 
> component and therefore won't have any problems being modified outside 
> of the EDT.  

To me this seems not to be a reason since I wouldn't consider the whole 
thing specific to the EDT.

If one modifies an object (an instance of BufferedImage) outside of one 
thread (the EDT) while this thread accesses it (during EDT's paint 
operation) there are two threads that access the same object.

The question then is if the object is in a determinable state at the 
time a thread accesses it.

Since the modifying thread is the only thread that changes the object's 
state, the modifying thread always gets an object whose state can be 
determined.

In general this isn't true to any other thread since it might get an 
object whose state is currently being modified.

So: Are there any guarantees that the EDT paint operation draws a 
BufferedImage that is in a state as it was before any Graphics (created 
via the BufferedImage) method was started that has not yet finished?

Bye
Michael

---
 * 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]

#1126

  To: comp.lang.java.gui
Michael Rauscher wrote:
> Knute Johnson wrote:
>> I don't have any links for you but BufferedImage is not a Swing 
>> component and therefore won't have any problems being modified outside 
>> of the EDT.  
> 
> To me this seems not to be a reason since I wouldn't consider the whole 
> thing specific to the EDT.
> 
> If one modifies an object (an instance of BufferedImage) outside of one 
> thread (the EDT) while this thread accesses it (during EDT's paint 
> operation) there are two threads that access the same object.
> 
> The question then is if the object is in a determinable state at the 
> time a thread accesses it.

Determinable yes.  The state you assume it is in because you have drawn 
on it, I don't know.  Doesn't matter in this case anyway.

> Since the modifying thread is the only thread that changes the object's 
> state, the modifying thread always gets an object whose state can be 
> determined.
> 
> In general this isn't true to any other thread since it might get an 
> object whose state is currently being modified.
> 
> So: Are there any guarantees that the EDT paint operation draws a 
> BufferedImage that is in a state as it was before any Graphics (created 
> via the BufferedImage) method was started that has not yet finished?

If you don't call repaint() until you are done drawing on it I doubt it. 
  If you queued a repaint() from another thread while you were in the 
process of doing a draw I don't think you could guarantee where in the 
draw you would be.  If multiple threads kept multiple copies of the same 
BufferedImage object then I think you could have a situation where you 
draw on your copy and the other thread doesn't see it yet.  I'm not 
really clear on when that can happen but synchronizing the code will 
certainly prevent that.  In reality I don't think it will ever be a problem.

-- 

Knute Johnson
email s/nospam/knute/

---
 * 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]

#1128

  To: comp.lang.java.gui
Knute Johnson wrote:
>> So: Are there any guarantees that the EDT paint operation draws a 
>> BufferedImage that is in a state as it was before any Graphics 
>> (created via the BufferedImage) method was started that has not yet 
>> finished?
> 
> If you don't call repaint() until you are done drawing on it I doubt it. 

The underlying system might cause a repaint, too.

>  If you queued a repaint() from another thread while you were in the 
> process of doing a draw I don't think you could guarantee where in the 
> draw you would be.  If multiple threads kept multiple copies of the same 
> BufferedImage object then I think you could have a situation where you 
> draw on your copy and the other thread doesn't see it yet.  I'm not 
> really clear on when that can happen but synchronizing the code will 
> certainly prevent that.  In reality I don't think it will ever be a 
> problem.

I used the EDT to serialize subsequent calls to Graphics-methods to 
prevent synchronizing. This way it's guaranteed that there's no drawXXX 
method running while paintComponent draws the image.

But you're right. I can't imagine a situation in which it would be a 
real problem if the Graphics-method was called from a non EDT-thread.

Thanks for clarifying this topic.

Bye
Michael

---
 * 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]

#1114

  To: comp.lang.java.gui

"Michael Rauscher" <michlmann@gmx.de> wrote in message 
news:eseihg$83f$1@registered.motzarella.org...
> Robert Sturzenegger wrote:
>>>> I would like to draw a graph in a container. Since the calculation of 
>>>> the graph may be very time consuming, I would like to watch how the 
>>>> graph builds up.
>
> Michael Rauscher wrote:
>
>>> If it's just for testing purposes, you could turn off Swing's double 
>>> buffering. Otherwise Andrew Thompson's method is much preferred.
>
> [Andrew Thompson suggested to remove the time consuming task from the 
> EDT].
>
> Robert Sturzenegger wrote:
>
>> I tried this and it really accomplishes what I want. Since you stated, 
>> that this solution should be for testing purposes only and that Andrew 
>> Thompson's method would be the preferred one, I also wanted to try his 
>> way. However I failed .... Details can be found in a response to his 
>> suggestion.
>
> The key is to separate the 'current state' of the drawing from the drawing 
> process.
>
> E.g. you might want to use a BufferedImage as offscreen image. 
> paintComponent simply draws that image on screen.
>
> private BufferedImage img = new BufferedImage(400, 400,
>         BufferedImage.TYPE_INT_ARGB);
>
> public void paintComponent( Graphics g ) {
>     g.drawImage( img, 0, 0, null );
> }
>
> In theory, you could now manipulate the image and call repaint to show the 
> result on screen. In practice, this is possible, too. The only thing you'd 
> have to care of, is to manipulate the image on the EDT.
>
> So:
>
> private void calculateAndPaint() {
>     for ( int x = 0; x < 200; ++x ) {
>         final int i = x;
>         SwingUtilities.invokeLater( new Runnable() {
>             public void run() {
>                 Graphics g = img.createGraphics();
>                 g.drawLine( i, i, i-1, i-1 );
>                 g.dispose();
>                 repaint();
>             }
>         });
>         try { Thread.sleep(10); } catch ( InterruptedException e ) {}
>     }
> }
>
> The last thing one has to do is to let calculateAndPaint be run on a new 
> Thread:
>
> public void paint() {
>     Thread t = new Thread( new Runnable() {
>         public void run() {
>             calculateAndPaint();
>         }
>     });
>     t.setPriority( Thread.NORM_PRIORITY );
>     t.start();
> }
>
> Bye
> Michael


I tried it and it works fine (according to the suggestion of Knute Johnson I 
don't use the EDT). This is exactly what I need.
Thank you very much!
Robert

---
 * 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