http://imagej.273.s1.nabble.com/Contradiction-with-show-method-tp3693120p3693126.html
my earlier comment agrees perfectly with Michael's statement.
Furthermore I'm convinced that anybody who uses Java for e.g. image
threading-issue. (I know what I'm speaking of.)
additions. But they are dialects, mostly with limited scope, and
future will offer. Fact is that already today OO makes threading much
arrays or other data structures". However, I'm pretty sure you know
> > -----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
>>