From roman at kennke.org  Fri Jun  1 05:30:16 2012
From: roman at kennke.org (roman at kennke.org)
Date: Fri, 01 Jun 2012 12:30:16 +0000
Subject: hg: caciocavallo/ng: Implement CacioToolkit.getScreenResolution().
Message-ID: <20120601123017.CDB9C4767E@hg.openjdk.java.net>

Changeset: ef51eb670980
Author:    Roman Kennke <rkennke at redhat.com>
Date:      2012-06-01 14:29 +0200
URL:       http://hg.openjdk.java.net/caciocavallo/ng/rev/ef51eb670980

Implement CacioToolkit.getScreenResolution().

! cacio-shared/src/main/java/sun/awt/peer/cacio/CacioToolkit.java
! cacio-tta/src/main/java/net/java/openjdk/cacio/ctc/CTCToolkit.java



From roman at kennke.org  Fri Jun  1 05:35:52 2012
From: roman at kennke.org (roman at kennke.org)
Date: Fri, 01 Jun 2012 12:35:52 +0000
Subject: hg: caciocavallo/ng: Implement CacioToolkit.getSystemClipboard().
Message-ID: <20120601123553.3F7274767F@hg.openjdk.java.net>

Changeset: d872ad00ac64
Author:    Roman Kennke <rkennke at redhat.com>
Date:      2012-06-01 14:35 +0200
URL:       http://hg.openjdk.java.net/caciocavallo/ng/rev/d872ad00ac64

Implement CacioToolkit.getSystemClipboard().

! cacio-shared/src/main/java/sun/awt/peer/cacio/CacioToolkit.java
! cacio-tta/src/main/java/net/java/openjdk/cacio/ctc/CTCToolkit.java



From roman at kennke.org  Fri Jun  1 06:39:00 2012
From: roman at kennke.org (roman at kennke.org)
Date: Fri, 01 Jun 2012 13:39:00 +0000
Subject: hg: caciocavallo/ng: Implement basic CacioMouseInfoPeer.
Message-ID: <20120601133900.DF00947683@hg.openjdk.java.net>

Changeset: 0e6628ed3289
Author:    Roman Kennke <rkennke at redhat.com>
Date:      2012-06-01 15:38 +0200
URL:       http://hg.openjdk.java.net/caciocavallo/ng/rev/0e6628ed3289

Implement basic CacioMouseInfoPeer.

+ cacio-shared/src/main/java/sun/awt/peer/cacio/CacioMouseInfoPeer.java
! cacio-shared/src/main/java/sun/awt/peer/cacio/CacioToolkit.java
! cacio-tta/src/main/java/net/java/openjdk/cacio/ctc/CTCRobotPeer.java
+ cacio-tta/src/test/java/net/java/openjdk/cacio/ctc/MouseInfoTest.java



From roman at kennke.org  Fri Jun  1 06:40:30 2012
From: roman at kennke.org (Roman Kennke)
Date: Fri, 01 Jun 2012 15:40:30 +0200
Subject: Issues with unsupported toolkit functionality
In-Reply-To: <1338466019.30788.14.camel@mercury.localdomain>
References: <CALdF2peG9ZpWEjGQUY9RC22_h2r9LnCSEZSdqNiD08teg9X=zA@mail.gmail.com>
	<1338466019.30788.14.camel@mercury.localdomain>
Message-ID: <1338558030.30964.6.camel@mercury.localdomain>

Am Donnerstag, den 31.05.2012, 14:06 +0200 schrieb Roman Kennke:
> Hi Martin,
> 
> > I'm currently porting our FEST test suite from using Xvnc to Cacio.
> > In general it seems to work quite well but there are a couple of
> > API-Methods of CTCToolkit which are not (really)
> >  implemented yet, although I think it should be quite simple to do so:
> > 
> > * currently the getScreenResolution() method returns 0, (which is
> > pretty much the worst number in this position)
> >   a constant 72 or 96 would help a lot.
> >   A possibility for dynamic configuration in tests would be great.
> >   We have a lot of Screenshot/Save Image actions which use this number
> > for a division and currently crash.
> 
> Right. This seems to be fairly easy to implement.
> 
> > * getSystemClipboard() currently returns null. Although I understand
> > that a fully-fledged implementation would require
> >   some intelligence but I believe in tests it would be sufficient to
> > create a singleton instance of Clipboard in the toolkit, that can
> >   be filled and read by java test and client code.
> 
> Yeah, I think that should be good enough especially for testing. For
> real platform ports, this would need to be integrated with the platform
> clipboard, but this is not part of core Cacio anyway.
> 
> 
> > * We are supporting only Oracle JDK. This works in general quite well
> > with Cacio, but there is an Issue in the following method:
> > 
> > sun.awt.DefaultMouseInfoPeer.fillPointWithCoords(Ljava/awt/Point;)Ijava.lang.UnsatisfiedLinkError:
> > sun.awt.DefaultMouseInfoPeer.fillPointWithCoords(Ljava/awt/Point;)I
> > 	at sun.awt.DefaultMouseInfoPeer.fillPointWithCoords(Native Method)
> 
> Oh yeah, we don't provide an implementation of that one yet, and it
> simply falls through to the JDK SunToolkit implementation, which of
> course does not work. Should be fairly easy to implement though.
> 
> 
> > These are my observations so far, anyway: Great Work, will save us a
> > lot of trouble in the future.
> 
> Thanks a lot! I will fix the above mentioned issues as soon as I find
> some time and then probably push out a release.

I just committed fixes for all 3 issues. Would you be able to check out
Cacio from Mercurial and try if it fixes your problems?

Cheers,
Roman




From fra.orolo at mailfish.de  Mon Jun 25 03:19:06 2012
From: fra.orolo at mailfish.de (fra.orolo at mailfish.de)
Date: Mon, 25 Jun 2012 12:19:06 +0200
Subject: Cacio is Leaking
Message-ID: <CALdF2pd0RWrxOuWkkJ0vsLJNmDChm=DfFzW2ebMK+PbrBHmwkg@mail.gmail.com>

[Second post with smaller attachments to get through]

Dear cacio developers,

I finally managed to get Cacio running as the GUI backend for running
tests in our CI system.
The preliminary fixes for clipboard and screen resolution helped a
lot. The problems on Windows have been
resolved by using Metal UI instead of Native LAF.

We discovered some more problems though:
 * We have one test where a visualizer with a rectangular grid is
tested for "box selection" gestures:

 Point lup = new Point(10,1);
 Point rlp = new Point(50,21);
 robot.pressMouse(target, lup, MouseButton.LEFT_BUTTON);
 robot.moveMouse(target, rlp);
 robot.releaseMouseButtons();

 This used to work with xvnc and generated mouse drag events that are
captured to select cells of the grid.
 These drag events are no longer generated.

* In some of our tests we open a Popup on a table, just to check
whether certain items are disabled.
 After this was done, the test did a click outside the popup to close it.
 This pattern breaks the test with Cacio, as this popup keeps the
keyboard focus and later text input actions fail, because
 they are unable to obtain the focus.

* The biggest issue last: Some of our tests are Memory Leak tests:
  0 They start an application
  1 load some dataset and
  2 perform some operations
  3 measure the allocated memory of the VM
  4 drop the dataset and repeat the cycle from step 1 (let's say 10
times or so)

 The expectation is that the allocated Memory should stay somehow
stable in step 3.
 I must at least not grow proportionally with the number of cycles.

 With Cacio as the backend we discovered a leak:

 The allWindows list in java.awt.Window contains references to some
old Dialogs which are created in step 2 and
 definitely have been dispose()d. This should remove the references
but apparently it doesn't.
 This works well with Xvnc as the backend.
 The attached screenshots from MemoryAnalyzer show that 12
FitLayerImpl objects are hanging in Memory, there should be only 1.
 The second shows the trace to the Heap root for one of them.

      Best regards
         Martin


From roman at kennke.org  Mon Jun 25 09:01:27 2012
From: roman at kennke.org (Roman Kennke)
Date: Mon, 25 Jun 2012 18:01:27 +0200
Subject: Cacio is Leaking
In-Reply-To: <CALdF2pd0RWrxOuWkkJ0vsLJNmDChm=DfFzW2ebMK+PbrBHmwkg@mail.gmail.com>
References: <CALdF2pd0RWrxOuWkkJ0vsLJNmDChm=DfFzW2ebMK+PbrBHmwkg@mail.gmail.com>
Message-ID: <4FE88B57.2010007@kennke.org>

Hi Martin,

Thanks for your continued efforts!> I finally managed to get Cacio 
running as the GUI backend for running
> tests in our CI system.
> The preliminary fixes for clipboard and screen resolution helped a
> lot. The problems on Windows have been
> resolved by using Metal UI instead of Native LAF.
>
> We discovered some more problems though:
>   * We have one test where a visualizer with a rectangular grid is
> tested for "box selection" gestures:
>
>   Point lup = new Point(10,1);
>   Point rlp = new Point(50,21);
>   robot.pressMouse(target, lup, MouseButton.LEFT_BUTTON);
>   robot.moveMouse(target, rlp);
>   robot.releaseMouseButtons();
>
>   This used to work with xvnc and generated mouse drag events that are
> captured to select cells of the grid.
>   These drag events are no longer generated.

I think this is not implemented yet. I will do this in the next days.

> * In some of our tests we open a Popup on a table, just to check
> whether certain items are disabled.
>   After this was done, the test did a click outside the popup to close it.
>   This pattern breaks the test with Cacio, as this popup keeps the
> keyboard focus and later text input actions fail, because
>   they are unable to obtain the focus.
>

Same here, I guess it's quite simply not implemented yet.

> * The biggest issue last: Some of our tests are Memory Leak tests:
>    0 They start an application
>    1 load some dataset and
>    2 perform some operations
>    3 measure the allocated memory of the VM
>    4 drop the dataset and repeat the cycle from step 1 (let's say 10
> times or so)
>
>   The expectation is that the allocated Memory should stay somehow
> stable in step 3.
>   I must at least not grow proportionally with the number of cycles.
>
>   With Cacio as the backend we discovered a leak:
>
>   The allWindows list in java.awt.Window contains references to some
> old Dialogs which are created in step 2 and
>   definitely have been dispose()d. This should remove the references
> but apparently it doesn't.

Hmm, I just wrote what I think is a minimal testcase, and it doesn't 
show an obvious memory leak. Can you provide a testcase that shows the 
leak ?

@RunWith(CacioFESTRunner.class)
public class TestLeakWindow {

     @Test
     public void test() {
         Window w = new Frame();
         w.dispose();
         w = null;
         System.gc();
         try {
             Thread.sleep(1000);
         } catch (InterruptedException ex) {
             Thread.currentThread().interrupt();
         }
         Window[] windows = Window.getWindows();
         assertEquals(0, windows.length);
     }

}

Best regards,

Roman


From roman at kennke.org  Mon Jun 25 11:13:26 2012
From: roman at kennke.org (Roman Kennke)
Date: Mon, 25 Jun 2012 20:13:26 +0200
Subject: Cacio is Leaking
In-Reply-To: <4FE88B57.2010007@kennke.org>
References: <CALdF2pd0RWrxOuWkkJ0vsLJNmDChm=DfFzW2ebMK+PbrBHmwkg@mail.gmail.com>
	<4FE88B57.2010007@kennke.org>
Message-ID: <4FE8AA46.1050607@kennke.org>

Am 25.06.2012 18:01, schrieb Roman Kennke:
> Hi Martin,
>
> Thanks for your continued efforts!> I finally managed to get Cacio
> running as the GUI backend for running
>> tests in our CI system.
>> The preliminary fixes for clipboard and screen resolution helped a
>> lot. The problems on Windows have been
>> resolved by using Metal UI instead of Native LAF.
>>
>> We discovered some more problems though:
>>   * We have one test where a visualizer with a rectangular grid is
>> tested for "box selection" gestures:
>>
>>   Point lup = new Point(10,1);
>>   Point rlp = new Point(50,21);
>>   robot.pressMouse(target, lup, MouseButton.LEFT_BUTTON);
>>   robot.moveMouse(target, rlp);
>>   robot.releaseMouseButtons();
>>
>>   This used to work with xvnc and generated mouse drag events that are
>> captured to select cells of the grid.
>>   These drag events are no longer generated.
>
> I think this is not implemented yet. I will do this in the next days.
>
>> * In some of our tests we open a Popup on a table, just to check
>> whether certain items are disabled.
>>   After this was done, the test did a click outside the popup to close
>> it.
>>   This pattern breaks the test with Cacio, as this popup keeps the
>> keyboard focus and later text input actions fail, because
>>   they are unable to obtain the focus.
>>
>
> Same here, I guess it's quite simply not implemented yet.
>
>> * The biggest issue last: Some of our tests are Memory Leak tests:
>>    0 They start an application
>>    1 load some dataset and
>>    2 perform some operations
>>    3 measure the allocated memory of the VM
>>    4 drop the dataset and repeat the cycle from step 1 (let's say 10
>> times or so)
>>
>>   The expectation is that the allocated Memory should stay somehow
>> stable in step 3.
>>   I must at least not grow proportionally with the number of cycles.
>>
>>   With Cacio as the backend we discovered a leak:
>>
>>   The allWindows list in java.awt.Window contains references to some
>> old Dialogs which are created in step 2 and
>>   definitely have been dispose()d. This should remove the references
>> but apparently it doesn't.
>
> Hmm, I just wrote what I think is a minimal testcase, and it doesn't
> show an obvious memory leak. Can you provide a testcase that shows the
> leak ?


Ok, I guess today is not my day. Of course, the leaky behaviour only 
shows when the window is actually made visible (because otherwise we 
don't even create a peer in the first place).


@RunWith(CacioFESTRunner.class)
public class TestLeakWindow {

     @Test
     public void test() {
         Window w = new Frame();
         w.setVisible(true);
         w.dispose();
         w = null;
         System.gc();
         try {
             Thread.sleep(1000);
         } catch (InterruptedException ex) {
             Thread.currentThread().interrupt();
         }
         Window[] windows = Window.getWindows();
         assertEquals(0, windows.length);
     }

}

I will debug and fix it asap.

Best regards,
Roman


From roman at kennke.org  Thu Jun 28 02:34:11 2012
From: roman at kennke.org (roman at kennke.org)
Date: Thu, 28 Jun 2012 09:34:11 +0000
Subject: hg: caciocavallo/ng: Fixed memory leak when disposing windows.
Message-ID: <20120628093413.7BC4547B90@hg.openjdk.java.net>

Changeset: ed85f837322f
Author:    Roman Kennke <rkennke at redhat.com>
Date:      2012-06-28 11:33 +0200
URL:       http://hg.openjdk.java.net/caciocavallo/ng/rev/ed85f837322f

Fixed memory leak when disposing windows.

! cacio-shared/src/main/java/sun/awt/peer/cacio/CacioComponentPeer.java
! cacio-shared/src/main/java/sun/awt/peer/cacio/CacioToolkit.java
! cacio-shared/src/main/java/sun/awt/peer/cacio/CacioWindowPeer.java
! cacio-shared/src/main/java/sun/awt/peer/cacio/ProxyWindowPeer.java
+ cacio-tta/src/test/java/net/java/openjdk/cacio/ctc/WindowLeakTest.java



From a.flaig at googlemail.com  Thu Jun 28 03:52:18 2012
From: a.flaig at googlemail.com (Albert Flaig)
Date: Thu, 28 Jun 2012 12:52:18 +0200
Subject: Cacio-Web
Message-ID: <CAPtepCv5SOa3t+4AdFgcf3xhf0W81wEtWZBYqds=5KA=LtRA0g@mail.gmail.com>

Hi there,

I need help deploying an existing swing gui on my server using
cacio-web. I couldn't find any tutorials that show a minimalist
example of deploying a swing gui to a server.

Greetings from Germany


From roman at kennke.org  Fri Jun 29 07:51:40 2012
From: roman at kennke.org (Roman Kennke)
Date: Fri, 29 Jun 2012 16:51:40 +0200
Subject: Cacio-Web
In-Reply-To: <CAPtepCv5SOa3t+4AdFgcf3xhf0W81wEtWZBYqds=5KA=LtRA0g@mail.gmail.com>
References: <CAPtepCv5SOa3t+4AdFgcf3xhf0W81wEtWZBYqds=5KA=LtRA0g@mail.gmail.com>
Message-ID: <4FEDC0FC.4050902@kennke.org>

Am 28.06.2012 12:52, schrieb Albert Flaig:
> Hi there,
>
> I need help deploying an existing swing gui on my server using
> cacio-web. I couldn't find any tutorials that show a minimalist
> example of deploying a swing gui to a server.

Hello Albert,

I am sorry, I don't think that there is any tutorial so far, at least 
none that I know of. I will write up something in the near future and 
get back to you.

Greetings from Germany as well!

Cheers,
Roman