I sent the question below earlier but solved it now.
In the event that anyone out there does have a similar
problem (in this obscure corner...) and would like some
info, just send me an email and I will be happy to
try to help,
Paul.
---------------------------------------------------------------------------
Paul Beardsley email: [EMAIL PROTECTED]
MERL - A Mitsubishi Electric Research Laboratory, tel: +(617) 621 7569
201 Broadway, Cambridge, MA 02139, USA fax: +(617) 621 7550
>
> I am using Java SDK 2 on Redhat 6.0. I have
> a Java GUI on a C++ library and have hit the
> following problem.
>
> The GUI includes a component like this for
> displaying images,
>
> class DisplayPanel extends JPanel
> {
> public void paintComponent (Graphics g)
> {
> super. paintComponent (g); // paint background
>
> // route 1
>
> g. drawImage (image, 0, 0, this);
>
> ... OR ...
>
> // route 2
>
> _interface_to_c++. display_image (g, this);
> }
> }
>
> If I use route 1, everything is fine, the
> image is displayed whenever it is required.
>
> Route 2 involves a call to a C++ routine, which
> takes an image from memory, wraps it up in the
> required Java format (using MemoryImageSource),
> then does a drawImage. However, the following
> problem occurs -
>
> paintComponent is invoked in the usual way,
> it calls the C++ routine, the image is
> displayed (correctly), the processing terminates,
> but then something causes paintComponent
> to be invoked again. It goes into a loop
> in which paintComponent is repeatedly invoked,
> and the C++ routine is continually drawing
> the image.
>
> Well the basic logic is ok on the Java side because
> route 1 works fine. So something in the C++ routine
> causes Java to think the DiplayPanel component
> needs to be updated. And it all hinges on the
> call to drawImage from C++ (if I remove that,
> no looping).
>
> I almost began to think it's a bug, that you can't use
> the JNI when displaying images. Any thoughts?
>
> Thanks,
> Paul.
>
> p.s. I tried things like "markCompletelyClean" on the component
> after return from C++ to try to disable the repaint but no luck.
>
> ---------------------------------------------------------------------------
> Paul Beardsley email: [EMAIL PROTECTED]
> MERL - A Mitsubishi Electric Research Laboratory, tel: +(617) 621 7569
> 201 Broadway, Cambridge, MA 02139, USA fax: +(617) 621 7550
>
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
