Login  Register

Re: Contradiction with show() method

Posted by Burger Wilhelm on Mar 31, 2009; 5:26pm
URL: http://imagej.273.s1.nabble.com/Contradiction-with-show-method-tp3693120p3693121.html

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
>