Contradiction with show() method
Locked
Contradiction with show() method
 
|
I am learning Java via th "monkey see, monkey do" method and get what seems
to be a contradiction. I ran a test similar to the one shown in Burger and Berge on page 502.(see run method below). Without the updateAndDraw(), the invert() result should not be display'ed. But, In case 1, with the wait(2000) and updateAndDraw() commented out, I get the inverted image being displayed (It shouldn't be). In case 2, I use the wait(200) and get only the original image being displayed. In case 3, I add the updateAndDraw() and get the inverted image. Only case 3 makes any sense public void run(ImageProcessor ip) { ImageProcessor ip1 = ip.duplicate(); ImagePlus im1 = new ImagePlus("im1",ip1); im1.show(); //IJ.wait(2000); ip1.invert(); //im1.updateAndDraw(); } David Webster |
Re: Contradiction with show() method
|
|
Running IJ 1.42h (under Windows XP, Java 1.6) I cannot confirm the described behavior for cases 1 and 2.
Without the call to updateAndDraw() the inverted image never shows. --Wilhelm ________________________________ Von: ImageJ Interest Group im Auftrag von David William Webster Gesendet: So 29.03.2009 22:34 An: [hidden email] Betreff: Contradiction with show() method I am learning Java via th "monkey see, monkey do" method and get what seems to be a contradiction. I ran a test similar to the one shown in Burger and Berge on page 502.(see run method below). Without the updateAndDraw(), the invert() result should not be display'ed. But, In case 1, with the wait(2000) and updateAndDraw() commented out, I get the inverted image being displayed (It shouldn't be). In case 2, I use the wait(200) and get only the original image being displayed. In case 3, I add the updateAndDraw() and get the inverted image. Only case 3 makes any sense public void run(ImageProcessor ip) { ImageProcessor ip1 = ip.duplicate(); ImagePlus im1 = new ImagePlus("im1",ip1); im1.show(); //IJ.wait(2000); ip1.invert(); //im1.updateAndDraw(); } David Webster |
Re: Contradiction with show() method
|
|
In reply to this post by David Webster
Hi David,
Java is multi-threaded; displaying images is usually done in a separate thread. Especially on multiprocessor machines, this improves performance. Thus, it can easily happen that "im1.show();" displays the image a few thenths of a second after that method is called; at that time the data are modified already. (not a bug, a feature ;-) Michael ________________________________________________________________ On 29 Mar 2009, at 22:34, David William Webster wrote: > I am learning Java via th "monkey see, monkey do" method and get > what seems > to be a contradiction. > > I ran a test similar to the one shown in Burger and Berge on page > 502.(see > run method below). Without the updateAndDraw(), the invert() > result should not be display'ed. But, > In case 1, with the wait(2000) and updateAndDraw() commented out, > I get the inverted image being displayed (It shouldn't be). > In case 2, I use the wait(200) and get only the original image being > displayed. > In case 3, I add the updateAndDraw() and get the inverted image. > Only case 3 makes any sense > > > public void run(ImageProcessor ip) { > > ImageProcessor ip1 = ip.duplicate(); > ImagePlus im1 = new ImagePlus("im1",ip1); > im1.show(); > //IJ.wait(2000); > ip1.invert(); > //im1.updateAndDraw(); > } > > David Webster |
Re: Contradiction with show() method
|
|
To All,
Wilhelm, I reran my tests and got the same results. Howeve, I should have included my case 2 as a normal result. Only case 1 seems to be odd. For what it's worth, I am using IJ 1.42k. Micheal, I am running Windows XP2002 SP3. I am using a Pentim 4 from 2005, that is only a single core. I don't know if it mutithreds or not. David On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid <[hidden email]>wrote: > Hi David, > > Java is multi-threaded; displaying images is usually done in a separate > thread. Especially on multiprocessor machines, this improves performance. > > Thus, it can easily happen that "im1.show();" displays the image a few > thenths of a second after that method is called; at that time the data are > modified already. > > (not a bug, a feature ;-) > > Michael > ________________________________________________________________ > > > On 29 Mar 2009, at 22:34, David William Webster wrote: > > I am learning Java via th "monkey see, monkey do" method and get what seems >> to be a contradiction. >> >> I ran a test similar to the one shown in Burger and Berge on page 502.(see >> run method below). Without the updateAndDraw(), the invert() >> result should not be display'ed. But, >> In case 1, with the wait(2000) and updateAndDraw() commented out, >> I get the inverted image being displayed (It shouldn't be). >> In case 2, I use the wait(200) and get only the original image being >> displayed. >> In case 3, I add the updateAndDraw() and get the inverted image. >> Only case 3 makes any sense >> >> >> public void run(ImageProcessor ip) { >> >> ImageProcessor ip1 = ip.duplicate(); >> ImagePlus im1 = new ImagePlus("im1",ip1); >> im1.show(); >> //IJ.wait(2000); >> ip1.invert(); >> //im1.updateAndDraw(); >> } >> >> David Webster >> > |
Re: Contradiction with show() method
|
|
David,
without going into the details of your problem, what you are experiencing is a peculiarity of the OO-trend in general and of Java (as an OO-language) in your specific situation. Objects in the first place have the property to exist and, well, only in the second place they may evolve or change... That said, procedures, such as those characteristic for signal processing tasks, must cope with the (in principle) parallel existence of objects in time. Now why are people using OO-languages to solve procedural problems? In the specific case because Java is, to a certain extent, platform independent. In general, because OO-languages are modern and under many circumstances easier to handle. Finally and quite important they allow for easier parallelisation of tasks, a property that in turn results from the more or less timeless parallel existence of objects. All that means for your problem that you have to take care for the correct sequence of what is handled in different threads which implies that you first need to know what is handle in different threads. Java provides tools for both but their application is sometimes a bit tricky. >To All, > >Wilhelm, I reran my tests and got the same results. Howeve, I should have >included my case 2 as a normal result. Only case 1 seems to be odd. For what >it's worth, I am using IJ 1.42k. > >Micheal, I am running Windows XP2002 SP3. I am using a Pentim 4 from 2005, >that is only a single core. I don't know if it mutithreds or not. >David Please note that multiple threads do not imply their distribution to several processors. Best Herbie >On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid ><[hidden email]>wrote: > >> Hi David, >> >> Java is multi-threaded; displaying images is usually done in a separate >> thread. Especially on multiprocessor machines, this improves performance. >> >> Thus, it can easily happen that "im1.show();" displays the image a few >> thenths of a second after that method is called; at that time the data are >> modified already. >> >> (not a bug, a feature ;-) >> >> Michael >> ________________________________________________________________ >> >> >> On 29 Mar 2009, at 22:34, David William Webster wrote: >> >> I am learning Java via th "monkey see, monkey do" method and get what seems >>> to be a contradiction. >>> >>> I ran a test similar to the one shown in Burger and Berge on page 502.(see >>> run method below). Without the updateAndDraw(), the invert() >>> result should not be display'ed. But, >>> In case 1, with the wait(2000) and updateAndDraw() commented out, >>> I get the inverted image being displayed (It shouldn't be). >>> In case 2, I use the wait(200) and get only the original image being >>> displayed. >>> In case 3, I add the updateAndDraw() and get the inverted image. >>> Only case 3 makes any sense >>> >>> >>> public void run(ImageProcessor ip) { >>> >>> ImageProcessor ip1 = ip.duplicate(); >>> ImagePlus im1 = new ImagePlus("im1",ip1); >>> im1.show(); >>> //IJ.wait(2000); >>> ip1.invert(); >>> //im1.updateAndDraw(); >>> } >>> > >> David Webster |
Re: Contradiction with show() method
|
|
In reply to this post by David Webster
Hi David,
as far as my experience told me, you have a separate thread for displaying images also on single-processor machines. I think that it is the paint method of ImageCanvas that runs in the separate thread, causing the behavior noticed by you. Swing components can have a paintSafely method that is not multi- threaded, but I don't think that you can have something like this with awt components used by ImageJ. The usual way of displaying an intermediate result of processing is to duplicate the ImageProcessor and use this copy for display only, without modifying it any further. Also note that ImageCanvas.paint is also called if an image gets obscured by a foreground image and has to be repainted. Thus I suspect that your method 3 would only work as long as the image stays in the foreground - but this may depend on whether the operating system or graphics card does some buffering or not. Michael ________________________________________________________________ On 30 Mar 2009, at 19:40, David Webster wrote: > To All, > > Wilhelm, I reran my tests and got the same results. Howeve, I > should have > included my case 2 as a normal result. Only case 1 seems to be odd. > For what > it's worth, I am using IJ 1.42k. > > Micheal, I am running Windows XP2002 SP3. I am using a Pentim 4 > from 2005, > that is only a single core. I don't know if it mutithreds or not. > > David > > > > On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid > <[hidden email]>wrote: > >> Hi David, >> >> Java is multi-threaded; displaying images is usually done in a >> separate >> thread. Especially on multiprocessor machines, this improves >> performance. >> >> Thus, it can easily happen that "im1.show();" displays the image a >> few >> thenths of a second after that method is called; at that time the >> data are >> modified already. >> >> (not a bug, a feature ;-) >> >> Michael >> ________________________________________________________________ >> >> >> On 29 Mar 2009, at 22:34, David William Webster wrote: >> >> I am learning Java via th "monkey see, monkey do" method and get >> what seems >>> to be a contradiction. >>> >>> I ran a test similar to the one shown in Burger and Berge on page >>> 502.(see >>> run method below). Without the updateAndDraw(), the invert() >>> result should not be display'ed. But, >>> In case 1, with the wait(2000) and updateAndDraw() commented out, >>> I get the inverted image being displayed (It shouldn't be). >>> In case 2, I use the wait(200) and get only the original image being >>> displayed. >>> In case 3, I add the updateAndDraw() and get the inverted image. >>> Only case 3 makes any sense >>> >>> >>> public void run(ImageProcessor ip) { >>> >>> ImageProcessor ip1 = ip.duplicate(); >>> ImagePlus im1 = new ImagePlus("im1",ip1); >>> im1.show(); >>> //IJ.wait(2000); >>> ip1.invert(); >>> //im1.updateAndDraw(); >>> } >>> >>> David Webster >>> >> |
Re: Contradiction with show() method
|
|
In reply to this post by David Webster
Dear Herbert,
as Michael explained correctly in his earlier response, that particular effect can be explained by display running in a separate thread. However, I don't think this has anything to do with OO-programming at all! It is certainly true that OO-programs do not execute linearly, as typical procedural programs would. However, parallelism is not an invention of object-orientation - in fact, some ancient FORTRAN and C dialects made it much easier to express parallelism than does Java, for example. Also, the noted "timeless parallel existence of objects" applies to any declared variables, arrays or other data structures in procedural programs as well. But perhaps I missed your real point? ... --Wilhelm > -----Original Message----- > From: ImageJ Interest Group [mailto:[hidden email]] On > Behalf Of Gluender > Sent: Tuesday, March 31, 2009 10:36 AM > To: [hidden email] > Subject: Re: Contradiction with show() method > > David, > > without going into the details of your problem, what you are > experiencing is a peculiarity of the OO-trend in general and of Java > (as an OO-language) in your specific situation. > > Objects in the first place have the property to exist and, well, only > in the second place they may evolve or change... > > That said, procedures, such as those characteristic for signal > processing tasks, must cope with the (in principle) parallel > existence of objects in time. > > Now why are people using OO-languages to solve procedural problems? > In the specific case because Java is, to a certain extent, platform > independent. > In general, because OO-languages are modern and under many > circumstances easier to handle. > Finally and quite important they allow for easier parallelisation of > tasks, a property that in turn results from the more or less timeless > parallel existence of objects. > > All that means for your problem that you have to take care for the > correct sequence of what is handled in different threads which > implies that you first need to know what is handle in different > threads. Java provides tools for both but their application is > sometimes a bit tricky. > > >To All, > > > >Wilhelm, I reran my tests and got the same results. Howeve, > I should have > >included my case 2 as a normal result. Only case 1 seems to > be odd. For what > >it's worth, I am using IJ 1.42k. > > > >Micheal, I am running Windows XP2002 SP3. I am using a > Pentim 4 from 2005, > >that is only a single core. I don't know if it mutithreds or not. > >David > > Please note that multiple threads do not imply their distribution to > several processors. > > Best > > Herbie > > >On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid > ><[hidden email]>wrote: > > > >> Hi David, > >> > >> Java is multi-threaded; displaying images is usually done > in a separate > >> thread. Especially on multiprocessor machines, this > improves performance. > >> > >> Thus, it can easily happen that "im1.show();" displays > the image a few > >> thenths of a second after that method is called; at that > time the data are > >> modified already. > >> > >> (not a bug, a feature ;-) > >> > >> Michael > >> ________________________________________________________________ > >> > >> > >> On 29 Mar 2009, at 22:34, David William Webster wrote: > >> > >> I am learning Java via th "monkey see, monkey do" method > and get what seems > >>> to be a contradiction. > >>> > >>> I ran a test similar to the one shown in Burger and > Berge on page 502.(see > >>> run method below). Without the updateAndDraw(), the invert() > >>> result should not be display'ed. But, > >>> In case 1, with the wait(2000) and updateAndDraw() > commented out, > >>> I get the inverted image being displayed (It shouldn't be). > >>> In case 2, I use the wait(200) and get only the original > image being > >>> displayed. > >>> In case 3, I add the updateAndDraw() and get the inverted image. > >>> Only case 3 makes any sense > >>> > >>> > >>> public void run(ImageProcessor ip) { > >>> > >>> ImageProcessor ip1 = ip.duplicate(); > >>> ImagePlus im1 = new ImagePlus("im1",ip1); > >>> im1.show(); > >>> //IJ.wait(2000); > >>> ip1.invert(); > >>> //im1.updateAndDraw(); > >>> } > >>> > > >> David Webster > |
Re: Contradiction with show() method
|
|
>Dear Herbert,
> >as Michael explained correctly in his earlier response, that particular >effect can be explained by display running in a separate thread. > >However, I don't think this has anything to do with OO-programming at >all! It is certainly true that OO-programs do not execute linearly, as >typical procedural programs would. However, parallelism is not an >invention of object-orientation - in fact, some ancient FORTRAN and C >dialects made it much easier to express parallelism than does Java, for >example. Also, the noted "timeless parallel existence of objects" >applies to any declared variables, arrays or other data structures in >procedural programs as well. > >But perhaps I missed your real point? ... >--Wilhelm Wilhelm, my earlier comment agrees perfectly with Michael's statement. Furthermore I'm convinced that anybody who uses Java for e.g. image processing will sooner or later be confronted with this or a similar threading-issue. (I know what I'm speaking of.) With respect to your interesting objection I should like to remind you that I wrote: "Finally and quite important they [00-languages] allow for easier parallelisation of tasks..." I haven't stated that there aren't different or earlier or procedural approaches for parallelism and I'm aware of such dialects and additions. But they are dialects, mostly with limited scope, and mainly used in high performance computing. As far as "easier" is concerned, we shall see what the multiprocessor future will offer. Fact is that already today OO makes threading much easier (in fact in many cases you don't have to care -- and may suffer from it, such as the original poster David) than the mentioned procedural languages that require, as you state correctly, special dialects or additions. Concerning "timeless parallel existence of objects" you certainly missed my point if you think of objects such as "declared variables, arrays or other data structures". However, I'm pretty sure you know how my perhaps somewhat abstract view relates to the issue. Have a good evening Herbie > > -----Original Message----- >> From: ImageJ Interest Group [mailto:[hidden email]] On >> Behalf Of Gluender >> Sent: Tuesday, March 31, 2009 10:36 AM >> To: [hidden email] >> Subject: Re: Contradiction with show() method >> >> David, >> >> without going into the details of your problem, what you are >> experiencing is a peculiarity of the OO-trend in general and of Java >> (as an OO-language) in your specific situation. >> >> Objects in the first place have the property to exist and, well, only >> in the second place they may evolve or change... >> >> That said, procedures, such as those characteristic for signal >> processing tasks, must cope with the (in principle) parallel >> existence of objects in time. >> >> Now why are people using OO-languages to solve procedural problems? >> In the specific case because Java is, to a certain extent, platform >> independent. >> In general, because OO-languages are modern and under many >> circumstances easier to handle. > > Finally and quite important they allow for easier parallelisation of >> tasks, a property that in turn results from the more or less timeless > > parallel existence of objects. >> >> All that means for your problem that you have to take care for the >> correct sequence of what is handled in different threads which >> implies that you first need to know what is handle in different >> threads. Java provides tools for both but their application is >> sometimes a bit tricky. >> >> >To All, >> > >> >Wilhelm, I reran my tests and got the same results. Howeve, >> I should have >> >included my case 2 as a normal result. Only case 1 seems to >> be odd. For what >> >it's worth, I am using IJ 1.42k. >> > >> >Micheal, I am running Windows XP2002 SP3. I am using a >> Pentim 4 from 2005, >> >that is only a single core. I don't know if it mutithreds or not. >> >David >> >> Please note that multiple threads do not imply their distribution to >> several processors. > > >> Best >> >> Herbie >> >> >On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid >> ><[hidden email]>wrote: >> > >> >> Hi David, >> >> >> >> Java is multi-threaded; displaying images is usually done >> in a separate >> >> thread. Especially on multiprocessor machines, this >> improves performance. >> >> >> >> Thus, it can easily happen that "im1.show();" displays >> the image a few >> >> thenths of a second after that method is called; at that >> time the data are >> >> modified already. >> >> >> >> (not a bug, a feature ;-) >> >> >> >> Michael >> >> ________________________________________________________________ >> >> >> >> >> >> On 29 Mar 2009, at 22:34, David William Webster wrote: >> >> >> >> I am learning Java via th "monkey see, monkey do" method >> and get what seems >> >>> to be a contradiction. >> >>> >> >>> I ran a test similar to the one shown in Burger and >> Berge on page 502.(see >> >>> run method below). Without the updateAndDraw(), the invert() >> >>> result should not be display'ed. But, >> >>> In case 1, with the wait(2000) and updateAndDraw() >> commented out, >> >>> I get the inverted image being displayed (It shouldn't be). >> >>> In case 2, I use the wait(200) and get only the original >> image being >> >>> displayed. >> >>> In case 3, I add the updateAndDraw() and get the inverted image. >> >>> Only case 3 makes any sense >> >>> >> >>> >> >>> public void run(ImageProcessor ip) { >> >>> >> >>> ImageProcessor ip1 = ip.duplicate(); >> >>> ImagePlus im1 = new ImagePlus("im1",ip1); >> >>> im1.show(); >> >>> //IJ.wait(2000); >> >>> ip1.invert(); >> >>> //im1.updateAndDraw(); >> >>> } >> >>> >> > >> David Webster >> -- Herbie ------------------------ <http://www.gluender.de> |
Re: Contradiction with show() method
|
|
In reply to this post by Burger Wilhelm
To All,
For what it’s worth, I wasn’t trying to “show” the results of the invert() before doing it. This was a completely unintended and unanticipated side effect. But now I’m wondering what other methods may run in separate threads. Is there a list? David Webster On Tue, Mar 31, 2009 at 11:37 AM, Gluender <[hidden email]> wrote: > Dear Herbert, >> >> as Michael explained correctly in his earlier response, that particular >> effect can be explained by display running in a separate thread. >> >> However, I don't think this has anything to do with OO-programming at >> all! It is certainly true that OO-programs do not execute linearly, as >> typical procedural programs would. However, parallelism is not an >> invention of object-orientation - in fact, some ancient FORTRAN and C >> dialects made it much easier to express parallelism than does Java, for >> example. Also, the noted "timeless parallel existence of objects" >> applies to any declared variables, arrays or other data structures in >> procedural programs as well. >> >> But perhaps I missed your real point? ... >> --Wilhelm >> > > Wilhelm, > > my earlier comment agrees perfectly with Michael's statement. Furthermore > I'm convinced that anybody who uses Java for e.g. image processing will > sooner or later be confronted with this or a similar threading-issue. (I > know what I'm speaking of.) > > With respect to your interesting objection I should like to remind you that > I wrote: > "Finally and quite important they [00-languages] allow for easier > parallelisation of tasks..." > > I haven't stated that there aren't different or earlier or procedural > approaches for parallelism and I'm aware of such dialects and additions. But > they are dialects, mostly with limited scope, and mainly used in high > performance computing. > > As far as "easier" is concerned, we shall see what the multiprocessor > future will offer. Fact is that already today OO makes threading much easier > (in fact in many cases you don't have to care -- and may suffer from it, > such as the original poster David) than the mentioned procedural languages > that require, as you state correctly, special dialects or additions. > > Concerning "timeless parallel existence of objects" you certainly missed my > point if you think of objects such as "declared variables, arrays or other > data structures". However, I'm pretty sure you know how my perhaps somewhat > abstract view relates to the issue. > > Have a good evening > > Herbie > > > > > -----Original Message----- >> >>> From: ImageJ Interest Group [mailto:[hidden email]] On >>> Behalf Of Gluender >>> Sent: Tuesday, March 31, 2009 10:36 AM >>> To: [hidden email] >>> Subject: Re: Contradiction with show() method >>> >>> David, >>> >>> without going into the details of your problem, what you are >>> experiencing is a peculiarity of the OO-trend in general and of Java >>> (as an OO-language) in your specific situation. >>> >>> Objects in the first place have the property to exist and, well, only >>> in the second place they may evolve or change... >>> >>> That said, procedures, such as those characteristic for signal >>> processing tasks, must cope with the (in principle) parallel >>> existence of objects in time. >>> >>> Now why are people using OO-languages to solve procedural problems? >>> In the specific case because Java is, to a certain extent, platform >>> independent. >>> In general, because OO-languages are modern and under many >>> circumstances easier to handle. >>> >> > Finally and quite important they allow for easier parallelisation of >> >>> tasks, a property that in turn results from the more or less timeless >>> >> > parallel existence of objects. >> >>> >>> All that means for your problem that you have to take care for the >>> correct sequence of what is handled in different threads which >>> implies that you first need to know what is handle in different >>> threads. Java provides tools for both but their application is >>> sometimes a bit tricky. >>> >>> >To All, >>> > >>> >Wilhelm, I reran my tests and got the same results. Howeve, >>> I should have >>> >included my case 2 as a normal result. Only case 1 seems to >>> be odd. For what >>> >it's worth, I am using IJ 1.42k. >>> > >>> >Micheal, I am running Windows XP2002 SP3. I am using a >>> Pentim 4 from 2005, >>> >that is only a single core. I don't know if it mutithreds or not. >>> >David >>> >>> Please note that multiple threads do not imply their distribution to >>> several processors. >>> >> > >> >>> Best >>> >>> Herbie >>> >>> >On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid >>> ><[hidden email]>wrote: >>> > >>> >> Hi David, >>> >> >>> >> Java is multi-threaded; displaying images is usually done >>> in a separate >>> >> thread. Especially on multiprocessor machines, this >>> improves performance. >>> >> >>> >> Thus, it can easily happen that "im1.show();" displays >>> the image a few >>> >> thenths of a second after that method is called; at that >>> time the data are >>> >> modified already. >>> >> >>> >> (not a bug, a feature ;-) >>> >> >>> >> Michael >>> >> ________________________________________________________________ >>> >> >>> >> >>> >> On 29 Mar 2009, at 22:34, David William Webster wrote: >>> >> >>> >> I am learning Java via th "monkey see, monkey do" method >>> and get what seems >>> >>> to be a contradiction. >>> >>> >>> >>> I ran a test similar to the one shown in Burger and >>> Berge on page 502.(see >>> >>> run method below). Without the updateAndDraw(), the invert() >>> >>> result should not be display'ed. But, >>> >>> In case 1, with the wait(2000) and updateAndDraw() >>> commented out, >>> >>> I get the inverted image being displayed (It shouldn't be). >>> >>> In case 2, I use the wait(200) and get only the original >>> image being >>> >>> displayed. >>> >>> In case 3, I add the updateAndDraw() and get the inverted image. >>> >>> Only case 3 makes any sense >>> >>> >>> >>> >>> >>> public void run(ImageProcessor ip) { >>> >>> >>> >>> ImageProcessor ip1 = ip.duplicate(); >>> >>> ImagePlus im1 = new ImagePlus("im1",ip1); >>> >>> im1.show(); >>> >>> //IJ.wait(2000); >>> >>> ip1.invert(); >>> >>> //im1.updateAndDraw(); >>> >>> } >>> >>> >>> > >> David Webster >>> >>> > > -- > > Herbie > > ------------------------ > <http://www.gluender.de> > |
Re: Contradiction with show() method
|
|
Hi David,
sorry, I don't think that there is any list of commands that run in a separate thread. Essentially all I/O and display operations can have a separate thread, and your code should be multi-thread save concerning everything that involves a callback from Java (such as the paint method). Commands that you invoke from the ImageJ menus have separate threads. So in principle you could process two images or image stacks at the same time (in different threads). But don't do it with the same filter! Many filters use static variables that do not allow them to run with different parameters in parallel threads. Anyhow, working on two stacks at the same time usually won't be any faster than doing it sequentially - most ImageJ stack operations use parallel threads on multiprocessor machines anyhow (Edit>Options>Memory&Threads). There is "single-thread list": You can be sure that you have only one thread within one plugin where it does not give control to Java or involve a callback - unless you explicitly invoke more than one thread (obviously, PlugInFilters with PARALLELIZE_STACKS and the "preview" function of ExtendedPlugInFilters can use multiple threads). Also, there is only one event queue (event dispatch thread). So callbacks of a dialog like mouseMoved, keyTyped, buttonPressed etc. will all run in the same thread, usually named 'AWT-EventQueue-0'. Also, it is guaranteed that the callbacks will be in the correct sequence. Hope this helps a bit. Michael ________________________________________________________________ On 31 Mar 2009, at 23:40, David Webster wrote: > To All, > > > For what it’s worth, I wasn’t trying to “show” the results of the > invert() > before doing it. This was a completely unintended and unanticipated > side > effect. But now I’m wondering what other methods may run in separate > threads. Is there a list? > > > David Webster > > > On Tue, Mar 31, 2009 at 11:37 AM, Gluender <[hidden email]> wrote: > >> Dear Herbert, >>> >>> as Michael explained correctly in his earlier response, that >>> particular >>> effect can be explained by display running in a separate thread. >>> >>> However, I don't think this has anything to do with OO- >>> programming at >>> all! It is certainly true that OO-programs do not execute >>> linearly, as >>> typical procedural programs would. However, parallelism is not an >>> invention of object-orientation - in fact, some ancient FORTRAN >>> and C >>> dialects made it much easier to express parallelism than does >>> Java, for >>> example. Also, the noted "timeless parallel existence of objects" >>> applies to any declared variables, arrays or other data >>> structures in >>> procedural programs as well. >>> >>> But perhaps I missed your real point? ... >>> --Wilhelm >>> >> >> Wilhelm, >> >> my earlier comment agrees perfectly with Michael's statement. >> Furthermore >> I'm convinced that anybody who uses Java for e.g. image processing >> will >> sooner or later be confronted with this or a similar threading- >> issue. (I >> know what I'm speaking of.) >> >> With respect to your interesting objection I should like to remind >> you that >> I wrote: >> "Finally and quite important they [00-languages] allow for easier >> parallelisation of tasks..." >> >> I haven't stated that there aren't different or earlier or procedural >> approaches for parallelism and I'm aware of such dialects and >> additions. But >> they are dialects, mostly with limited scope, and mainly used in high >> performance computing. >> >> As far as "easier" is concerned, we shall see what the multiprocessor >> future will offer. Fact is that already today OO makes threading >> much easier >> (in fact in many cases you don't have to care -- and may suffer >> from it, >> such as the original poster David) than the mentioned procedural >> languages >> that require, as you state correctly, special dialects or additions. >> >> Concerning "timeless parallel existence of objects" you certainly >> missed my >> point if you think of objects such as "declared variables, arrays >> or other >> data structures". However, I'm pretty sure you know how my perhaps >> somewhat >> abstract view relates to the issue. >> >> Have a good evening >> >> Herbie >> >> >> >>> -----Original Message----- >>> >>>> From: ImageJ Interest Group [mailto:[hidden email]] On >>>> Behalf Of Gluender >>>> Sent: Tuesday, March 31, 2009 10:36 AM >>>> To: [hidden email] >>>> Subject: Re: Contradiction with show() method >>>> >>>> David, >>>> >>>> without going into the details of your problem, what you are >>>> experiencing is a peculiarity of the OO-trend in general and of >>>> Java >>>> (as an OO-language) in your specific situation. >>>> >>>> Objects in the first place have the property to exist and, >>>> well, only >>>> in the second place they may evolve or change... >>>> >>>> That said, procedures, such as those characteristic for signal >>>> processing tasks, must cope with the (in principle) parallel >>>> existence of objects in time. >>>> >>>> Now why are people using OO-languages to solve procedural >>>> problems? >>>> In the specific case because Java is, to a certain extent, >>>> platform >>>> independent. >>>> In general, because OO-languages are modern and under many >>>> circumstances easier to handle. >>>> >>>> Finally and quite important they allow for easier >>>> parallelisation of >>> >>>> tasks, a property that in turn results from the more or less >>>> timeless >>>> >>>> parallel existence of objects. >>> >>>> >>>> All that means for your problem that you have to take care for the >>>> correct sequence of what is handled in different threads which >>>> implies that you first need to know what is handle in different >>>> threads. Java provides tools for both but their application is >>>> sometimes a bit tricky. >>>> >>>>> To All, >>>>> >>>>> Wilhelm, I reran my tests and got the same results. Howeve, >>>> I should have >>>>> included my case 2 as a normal result. Only case 1 seems to >>>> be odd. For what >>>>> it's worth, I am using IJ 1.42k. >>>>> >>>>> Micheal, I am running Windows XP2002 SP3. I am using a >>>> Pentim 4 from 2005, >>>>> that is only a single core. I don't know if it mutithreds or not. >>>>> David >>>> >>>> Please note that multiple threads do not imply their >>>> distribution to >>>> several processors. >>>> >>>> >>> >>>> Best >>>> >>>> Herbie >>>> >>>>> On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid >>>>> <[hidden email]>wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> Java is multi-threaded; displaying images is usually done >>>> in a separate >>>>>> thread. Especially on multiprocessor machines, this >>>> improves performance. >>>>>> >>>>>> Thus, it can easily happen that "im1.show();" displays >>>> the image a few >>>>>> thenths of a second after that method is called; at that >>>> time the data are >>>>>> modified already. >>>>>> >>>>>> (not a bug, a feature ;-) >>>>>> >>>>>> Michael >>>>>> ________________________________________________________________ >>>>>> >>>>>> >>>>>> On 29 Mar 2009, at 22:34, David William Webster wrote: >>>>>> >>>>>> I am learning Java via th "monkey see, monkey do" method >>>> and get what seems >>>>>>> to be a contradiction. >>>>>>> >>>>>>> I ran a test similar to the one shown in Burger and >>>> Berge on page 502.(see >>>>>>> run method below). Without the updateAndDraw(), the invert() >>>>>>> result should not be display'ed. But, >>>>>>> In case 1, with the wait(2000) and updateAndDraw() >>>> commented out, >>>>>>> I get the inverted image being displayed (It shouldn't be). >>>>>>> In case 2, I use the wait(200) and get only the original >>>> image being >>>>>>> displayed. >>>>>>> In case 3, I add the updateAndDraw() and get the inverted >>>>>>> image. >>>>>>> Only case 3 makes any sense >>>>>>> >>>>>>> >>>>>>> public void run(ImageProcessor ip) { >>>>>>> >>>>>>> ImageProcessor ip1 = ip.duplicate(); >>>>>>> ImagePlus im1 = new ImagePlus >>>>>>> ("im1",ip1); >>>>>>> im1.show(); >>>>>>> //IJ.wait(2000); >>>>>>> ip1.invert(); >>>>>>> //im1.updateAndDraw(); >>>>>>> } >>>>>>> >>>>>>> David Webster >>>> >>>> >> >> -- >> >> Herbie >> >> ------------------------ >> <http://www.gluender.de> >> |
Re: Contradiction with show() method
|
|
Micheal,
My concern was/is unanticipated side effects like the one I got with show() then invert(). For example, if I ran two different filters in sequence (in the source code) that actually ran in sepaate threads, then would I need to worry about the results from the second filter affecting the first filter. David Webster On Wed, Apr 1, 2009 at 7:37 AM, Michael Schmid <[hidden email]>wrote: > Hi David, > > sorry, I don't think that there is any list of commands that run in a > separate thread. Essentially all I/O and display operations can have a > separate thread, and your code should be multi-thread save concerning > everything that involves a callback from Java (such as the paint method). > > Commands that you invoke from the ImageJ menus have separate threads. So in > principle you could process two images or image stacks at the same time (in > different threads). But don't do it with the same filter! Many filters use > static variables that do not allow them to run with different parameters in > parallel threads. Anyhow, working on two stacks at the same time usually > won't be any faster than doing it sequentially - most ImageJ stack > operations use parallel threads on multiprocessor machines anyhow > (Edit>Options>Memory&Threads). > > There is "single-thread list": > > You can be sure that you have only one thread within one plugin where it > does not give control to Java or involve a callback - unless you explicitly > invoke more than one thread (obviously, PlugInFilters with > PARALLELIZE_STACKS and the "preview" function of ExtendedPlugInFilters can > use multiple threads). > > Also, there is only one event queue (event dispatch thread). So callbacks > of a dialog like mouseMoved, keyTyped, buttonPressed etc. will all run in > the same thread, usually named 'AWT-EventQueue-0'. Also, it is guaranteed > that the callbacks will be in the correct sequence. > > Hope this helps a bit. > > > Michael > ________________________________________________________________ > > > On 31 Mar 2009, at 23:40, David Webster wrote: > > To All, >> >> >> For what it’s worth, I wasn’t trying to “show” the results of the >> invert() >> before doing it. This was a completely unintended and unanticipated side >> effect. But now I’m wondering what other methods may run in separate >> threads. Is there a list? >> >> >> David Webster >> >> >> On Tue, Mar 31, 2009 at 11:37 AM, Gluender <[hidden email]> wrote: >> >> Dear Herbert, >>> >>>> >>>> as Michael explained correctly in his earlier response, that particular >>>> effect can be explained by display running in a separate thread. >>>> >>>> However, I don't think this has anything to do with OO-programming at >>>> all! It is certainly true that OO-programs do not execute linearly, as >>>> typical procedural programs would. However, parallelism is not an >>>> invention of object-orientation - in fact, some ancient FORTRAN and C >>>> dialects made it much easier to express parallelism than does Java, for >>>> example. Also, the noted "timeless parallel existence of objects" >>>> applies to any declared variables, arrays or other data structures in >>>> procedural programs as well. >>>> >>>> But perhaps I missed your real point? ... >>>> --Wilhelm >>>> >>>> >>> Wilhelm, >>> >>> my earlier comment agrees perfectly with Michael's statement. Furthermore >>> I'm convinced that anybody who uses Java for e.g. image processing will >>> sooner or later be confronted with this or a similar threading-issue. (I >>> know what I'm speaking of.) >>> >>> With respect to your interesting objection I should like to remind you >>> that >>> I wrote: >>> "Finally and quite important they [00-languages] allow for easier >>> parallelisation of tasks..." >>> >>> I haven't stated that there aren't different or earlier or procedural >>> approaches for parallelism and I'm aware of such dialects and additions. >>> But >>> they are dialects, mostly with limited scope, and mainly used in high >>> performance computing. >>> >>> As far as "easier" is concerned, we shall see what the multiprocessor >>> future will offer. Fact is that already today OO makes threading much >>> easier >>> (in fact in many cases you don't have to care -- and may suffer from it, >>> such as the original poster David) than the mentioned procedural >>> languages >>> that require, as you state correctly, special dialects or additions. >>> >>> Concerning "timeless parallel existence of objects" you certainly missed >>> my >>> point if you think of objects such as "declared variables, arrays or >>> other >>> data structures". However, I'm pretty sure you know how my perhaps >>> somewhat >>> abstract view relates to the issue. >>> >>> Have a good evening >>> >>> Herbie >>> >>> >>> >>> -----Original Message----- >>>> >>>> From: ImageJ Interest Group [mailto:[hidden email]] On >>>>> Behalf Of Gluender >>>>> Sent: Tuesday, March 31, 2009 10:36 AM >>>>> To: [hidden email] >>>>> Subject: Re: Contradiction with show() method >>>>> >>>>> David, >>>>> >>>>> without going into the details of your problem, what you are >>>>> experiencing is a peculiarity of the OO-trend in general and of Java >>>>> (as an OO-language) in your specific situation. >>>>> >>>>> Objects in the first place have the property to exist and, well, only >>>>> in the second place they may evolve or change... >>>>> >>>>> That said, procedures, such as those characteristic for signal >>>>> processing tasks, must cope with the (in principle) parallel >>>>> existence of objects in time. >>>>> >>>>> Now why are people using OO-languages to solve procedural problems? >>>>> In the specific case because Java is, to a certain extent, platform >>>>> independent. >>>>> In general, because OO-languages are modern and under many >>>>> circumstances easier to handle. >>>>> >>>>> Finally and quite important they allow for easier parallelisation of >>>>> >>>> >>>> tasks, a property that in turn results from the more or less timeless >>>>> >>>>> parallel existence of objects. >>>>> >>>> >>>> >>>>> All that means for your problem that you have to take care for the >>>>> correct sequence of what is handled in different threads which >>>>> implies that you first need to know what is handle in different >>>>> threads. Java provides tools for both but their application is >>>>> sometimes a bit tricky. >>>>> >>>>> To All, >>>>>> >>>>>> Wilhelm, I reran my tests and got the same results. Howeve, >>>>>> >>>>> I should have >>>>> >>>>>> included my case 2 as a normal result. Only case 1 seems to >>>>>> >>>>> be odd. For what >>>>> >>>>>> it's worth, I am using IJ 1.42k. >>>>>> >>>>>> Micheal, I am running Windows XP2002 SP3. I am using a >>>>>> >>>>> Pentim 4 from 2005, >>>>> >>>>>> that is only a single core. I don't know if it mutithreds or not. >>>>>> David >>>>>> >>>>> >>>>> Please note that multiple threads do not imply their distribution to >>>>> several processors. >>>>> >>>>> >>>>> >>>> Best >>>>> >>>>> Herbie >>>>> >>>>> On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid >>>>>> <[hidden email]>wrote: >>>>>> >>>>>> Hi David, >>>>>>> >>>>>>> Java is multi-threaded; displaying images is usually done >>>>>>> >>>>>> in a separate >>>>> >>>>>> thread. Especially on multiprocessor machines, this >>>>>>> >>>>>> improves performance. >>>>> >>>>>> >>>>>>> Thus, it can easily happen that "im1.show();" displays >>>>>>> >>>>>> the image a few >>>>> >>>>>> thenths of a second after that method is called; at that >>>>>>> >>>>>> time the data are >>>>> >>>>>> modified already. >>>>>>> >>>>>>> (not a bug, a feature ;-) >>>>>>> >>>>>>> Michael >>>>>>> ________________________________________________________________ >>>>>>> >>>>>>> >>>>>>> On 29 Mar 2009, at 22:34, David William Webster wrote: >>>>>>> >>>>>>> I am learning Java via th "monkey see, monkey do" method >>>>>>> >>>>>> and get what seems >>>>> >>>>>> to be a contradiction. >>>>>>>> >>>>>>>> I ran a test similar to the one shown in Burger and >>>>>>>> >>>>>>> Berge on page 502.(see >>>>> >>>>>> run method below). Without the updateAndDraw(), the invert() >>>>>>>> result should not be display'ed. But, >>>>>>>> In case 1, with the wait(2000) and updateAndDraw() >>>>>>>> >>>>>>> commented out, >>>>> >>>>>> I get the inverted image being displayed (It shouldn't be). >>>>>>>> In case 2, I use the wait(200) and get only the original >>>>>>>> >>>>>>> image being >>>>> >>>>>> displayed. >>>>>>>> In case 3, I add the updateAndDraw() and get the inverted image. >>>>>>>> Only case 3 makes any sense >>>>>>>> >>>>>>>> >>>>>>>> public void run(ImageProcessor ip) { >>>>>>>> >>>>>>>> ImageProcessor ip1 = ip.duplicate(); >>>>>>>> ImagePlus im1 = new ImagePlus("im1",ip1); >>>>>>>> im1.show(); >>>>>>>> //IJ.wait(2000); >>>>>>>> ip1.invert(); >>>>>>>> //im1.updateAndDraw(); >>>>>>>> } >>>>>>>> >>>>>>>> David Webster >>>>>>>> >>>>>>> >>>>> >>>>> >>> -- >>> >>> Herbie >>> >>> ------------------------ >>> <http://www.gluender.de> >>> >>> |
Re: Contradiction with show() method
|
|
Hi David,
if you use IJ.run(...) commands, the operations should be executed in the proper sequence. If they aren't, it is a bug - one can never exclude this, but it is not very likely. Direct calls to the PluginFilter methods should not be a problem at all - no separate threads will be involved. In ImageJ 1.39e and earlier versions, there has been a problem related to the multi-threaded nature of Java with new images created by some commands not available in time for the next command. Since then, I think that I have not seen any multithreading problem. Michael ________________________________________________________________ On 1 Apr 2009, at 20:07, David Webster wrote: > Micheal, > > My concern was/is unanticipated side effects like the one I got with > show() then invert(). For example, if I ran two different filters in > sequence (in the source code) that actually ran in sepaate > threads, then > would I need to worry about the results from the second filter > affecting the > first filter. > > David Webster > > On Wed, Apr 1, 2009 at 7:37 AM, Michael Schmid > <[hidden email]>wrote: > >> Hi David, >> >> sorry, I don't think that there is any list of commands that run in a >> separate thread. Essentially all I/O and display operations can >> have a >> separate thread, and your code should be multi-thread save concerning >> everything that involves a callback from Java (such as the paint >> method). >> >> Commands that you invoke from the ImageJ menus have separate >> threads. So in >> principle you could process two images or image stacks at the same >> time (in >> different threads). But don't do it with the same filter! Many >> filters use >> static variables that do not allow them to run with different >> parameters in >> parallel threads. Anyhow, working on two stacks at the same time >> usually >> won't be any faster than doing it sequentially - most ImageJ stack >> operations use parallel threads on multiprocessor machines anyhow >> (Edit>Options>Memory&Threads). >> >> There is "single-thread list": >> >> You can be sure that you have only one thread within one plugin >> where it >> does not give control to Java or involve a callback - unless you >> explicitly >> invoke more than one thread (obviously, PlugInFilters with >> PARALLELIZE_STACKS and the "preview" function of >> ExtendedPlugInFilters can >> use multiple threads). >> >> Also, there is only one event queue (event dispatch thread). So >> callbacks >> of a dialog like mouseMoved, keyTyped, buttonPressed etc. will all >> run in >> the same thread, usually named 'AWT-EventQueue-0'. Also, it is >> guaranteed >> that the callbacks will be in the correct sequence. >> >> Hope this helps a bit. >> >> >> Michael >> ________________________________________________________________ >> >> >> On 31 Mar 2009, at 23:40, David Webster wrote: >> >> To All, >>> >>> >>> For what it’s worth, I wasn’t trying to “show” the results of the >>> invert() >>> before doing it. This was a completely unintended and >>> unanticipated side >>> effect. But now I’m wondering what other methods may run in separate >>> threads. Is there a list? >>> >>> >>> David Webster >>> >>> >>> On Tue, Mar 31, 2009 at 11:37 AM, Gluender <[hidden email]> wrote: >>> >>> Dear Herbert, >>>> >>>>> >>>>> as Michael explained correctly in his earlier response, that >>>>> particular >>>>> effect can be explained by display running in a separate thread. >>>>> >>>>> However, I don't think this has anything to do with OO- >>>>> programming at >>>>> all! It is certainly true that OO-programs do not execute >>>>> linearly, as >>>>> typical procedural programs would. However, parallelism is not an >>>>> invention of object-orientation - in fact, some ancient FORTRAN >>>>> and C >>>>> dialects made it much easier to express parallelism than does >>>>> Java, for >>>>> example. Also, the noted "timeless parallel existence of objects" >>>>> applies to any declared variables, arrays or other data >>>>> structures in >>>>> procedural programs as well. >>>>> >>>>> But perhaps I missed your real point? ... >>>>> --Wilhelm >>>>> >>>>> >>>> Wilhelm, >>>> >>>> my earlier comment agrees perfectly with Michael's statement. >>>> Furthermore >>>> I'm convinced that anybody who uses Java for e.g. image >>>> processing will >>>> sooner or later be confronted with this or a similar threading- >>>> issue. (I >>>> know what I'm speaking of.) >>>> >>>> With respect to your interesting objection I should like to >>>> remind you >>>> that >>>> I wrote: >>>> "Finally and quite important they [00-languages] allow for easier >>>> parallelisation of tasks..." >>>> >>>> I haven't stated that there aren't different or earlier or >>>> procedural >>>> approaches for parallelism and I'm aware of such dialects and >>>> additions. >>>> But >>>> they are dialects, mostly with limited scope, and mainly used in >>>> high >>>> performance computing. >>>> >>>> As far as "easier" is concerned, we shall see what the >>>> multiprocessor >>>> future will offer. Fact is that already today OO makes threading >>>> much >>>> easier >>>> (in fact in many cases you don't have to care -- and may suffer >>>> from it, >>>> such as the original poster David) than the mentioned procedural >>>> languages >>>> that require, as you state correctly, special dialects or >>>> additions. >>>> >>>> Concerning "timeless parallel existence of objects" you >>>> certainly missed >>>> my >>>> point if you think of objects such as "declared variables, >>>> arrays or >>>> other >>>> data structures". However, I'm pretty sure you know how my perhaps >>>> somewhat >>>> abstract view relates to the issue. >>>> >>>> Have a good evening >>>> >>>> Herbie >>>> >>>> >>>> >>>> -----Original Message----- >>>>> >>>>> From: ImageJ Interest Group [mailto:[hidden email]] On >>>>>> Behalf Of Gluender >>>>>> Sent: Tuesday, March 31, 2009 10:36 AM >>>>>> To: [hidden email] >>>>>> Subject: Re: Contradiction with show() method >>>>>> >>>>>> David, >>>>>> >>>>>> without going into the details of your problem, what you are >>>>>> experiencing is a peculiarity of the OO-trend in general and >>>>>> of Java >>>>>> (as an OO-language) in your specific situation. >>>>>> >>>>>> Objects in the first place have the property to exist and, >>>>>> well, only >>>>>> in the second place they may evolve or change... >>>>>> >>>>>> That said, procedures, such as those characteristic for signal >>>>>> processing tasks, must cope with the (in principle) parallel >>>>>> existence of objects in time. >>>>>> >>>>>> Now why are people using OO-languages to solve procedural >>>>>> problems? >>>>>> In the specific case because Java is, to a certain extent, >>>>>> platform >>>>>> independent. >>>>>> In general, because OO-languages are modern and under many >>>>>> circumstances easier to handle. >>>>>> >>>>>> Finally and quite important they allow for easier >>>>>> parallelisation of >>>>>> >>>>> >>>>> tasks, a property that in turn results from the more or less >>>>> timeless >>>>>> >>>>>> parallel existence of objects. >>>>>> >>>>> >>>>> >>>>>> All that means for your problem that you have to take care >>>>>> for the >>>>>> correct sequence of what is handled in different threads which >>>>>> implies that you first need to know what is handle in different >>>>>> threads. Java provides tools for both but their application is >>>>>> sometimes a bit tricky. >>>>>> >>>>>> To All, >>>>>>> >>>>>>> Wilhelm, I reran my tests and got the same results. Howeve, >>>>>>> >>>>>> I should have >>>>>> >>>>>>> included my case 2 as a normal result. Only case 1 seems to >>>>>>> >>>>>> be odd. For what >>>>>> >>>>>>> it's worth, I am using IJ 1.42k. >>>>>>> >>>>>>> Micheal, I am running Windows XP2002 SP3. I am using a >>>>>>> >>>>>> Pentim 4 from 2005, >>>>>> >>>>>>> that is only a single core. I don't know if it mutithreds or >>>>>>> not. >>>>>>> David >>>>>>> >>>>>> >>>>>> Please note that multiple threads do not imply their >>>>>> distribution to >>>>>> several processors. >>>>>> >>>>>> >>>>>> >>>>> Best >>>>>> >>>>>> Herbie >>>>>> >>>>>> On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid >>>>>>> <[hidden email]>wrote: >>>>>>> >>>>>>> Hi David, >>>>>>>> >>>>>>>> Java is multi-threaded; displaying images is usually done >>>>>>>> >>>>>>> in a separate >>>>>> >>>>>>> thread. Especially on multiprocessor machines, this >>>>>>>> >>>>>>> improves performance. >>>>>> >>>>>>> >>>>>>>> Thus, it can easily happen that "im1.show();" displays >>>>>>>> >>>>>>> the image a few >>>>>> >>>>>>> thenths of a second after that method is called; at that >>>>>>>> >>>>>>> time the data are >>>>>> >>>>>>> modified already. >>>>>>>> >>>>>>>> (not a bug, a feature ;-) >>>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>> _______________________________________________________________ >>>>>>>> _ >>>>>>>> >>>>>>>> >>>>>>>> On 29 Mar 2009, at 22:34, David William Webster wrote: >>>>>>>> >>>>>>>> I am learning Java via th "monkey see, monkey do" method >>>>>>>> >>>>>>> and get what seems >>>>>> >>>>>>> to be a contradiction. >>>>>>>>> >>>>>>>>> I ran a test similar to the one shown in Burger and >>>>>>>>> >>>>>>>> Berge on page 502.(see >>>>>> >>>>>>> run method below). Without the updateAndDraw(), the invert() >>>>>>>>> result should not be display'ed. But, >>>>>>>>> In case 1, with the wait(2000) and updateAndDraw() >>>>>>>>> >>>>>>>> commented out, >>>>>> >>>>>>> I get the inverted image being displayed (It shouldn't be). >>>>>>>>> In case 2, I use the wait(200) and get only the original >>>>>>>>> >>>>>>>> image being >>>>>> >>>>>>> displayed. >>>>>>>>> In case 3, I add the updateAndDraw() and get the inverted >>>>>>>>> image. >>>>>>>>> Only case 3 makes any sense >>>>>>>>> >>>>>>>>> >>>>>>>>> public void run(ImageProcessor ip) { >>>>>>>>> >>>>>>>>> ImageProcessor ip1 = ip.duplicate(); >>>>>>>>> ImagePlus im1 = new ImagePlus >>>>>>>>> ("im1",ip1); >>>>>>>>> im1.show(); >>>>>>>>> //IJ.wait(2000); >>>>>>>>> ip1.invert(); >>>>>>>>> //im1.updateAndDraw(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> David Webster >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> -- >>>> >>>> Herbie >>>> >>>> ------------------------ >>>> <http://www.gluender.de> >>>> >>>> |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |