JXMapKit/-Viewer bardzo wolno jako webstartowalny - od czego zacząć kopanie?

Question

Po prostu próbowałem dodać niektóre elementy swingx-ws do ogólnych demonstracji swinglabs - i zauważyłem, że prosty JXMapKit/-Viewer jest wolniejszymi rzędami woluminów ładować płytki w webstartable w porównaniu do ładowania lokalnie.

raczej stracił gdzie powinienem zacząć szukać (UI aktualizacje wydają się być na EDT, choć może trzeba się bliżej):

• ktoś inny przeżywa różne czasy ładowania?
• Jakiekolwiek domysły na temat tego, z jakiego powodu?
• jak debugować webstartow?

Kod jest dość prosta (aby uruchomić lokalnie, trzeba swingx and swingx-ws:

public class WSDemo { 

    private JComponent createContent() { 
     JComponent content = new JPanel(); 
     content.setLayout(new BorderLayout()); 

     content.add(createMapKit()); 
     return content; 
    } 

    protected JComponent createMapKit() { 
     final int max = 17; 
     TileFactoryInfo info = new TileFactoryInfo(1, max - 2, max, 256, true, 
       true, // tile size is 256 and x/y orientation is normal 
       "http://tile.openstreetmap.org",// 5/15/10.png", 
       "x", "y", "z") { 
      public String getTileUrl(int x, int y, int zoom) { 
       zoom = max - zoom; 
       String url = this.baseURL + "/" + zoom + "/" + x + "/" + y 
         + ".png"; 
       return url; 
      } 

     }; 
     DefaultTileFactory tf = new DefaultTileFactory(info); 
     tf.setThreadPoolSize(1); 
     final JXMapKit kit = new JXMapKit(); 
     kit.setTileFactory(tf); 
     kit.setZoom(10); 
     kit.setAddressLocation(new GeoPosition(51.5, 0)); 
     kit.getMainMap().setDrawTileBorders(true); 
     return kit; 
    } 

    public static void main(String[] args) { 
     SwingUtilities.invokeLater(new Runnable() { 
      public void run() { 
       JFrame frame = new JFrame(""); 
       frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 
       frame.add(new WSDemo().createContent()); 
       frame.setLocationByPlatform(true); 
       frame.setSize(400, 400); 
       frame.setVisible(true); 
      } 
     }); 
    } 

} 

Edit:

Wygląda na to jakiś sposób związane z pozwoleniem kontroli w kontekście internetowej: profilowanie pokazuje, że cały zestaw wywołań połączenia jest inny (niezbyt zaskakujący) i trwa wieki. Rezygnacja na razie ..

Edycja 2:

Wydaje się 2 oddzielne kwestie

• Nieco dłuższy czas potrzebny do otwarcia połączenia do załadunku płytek w zastrzeżonej kontekście, że jest hotspot w JavaWebStartSecurity. checkConnect (String, int), jak @Howard już odnotowany.
• raczej dziwne blokowanie EDT, który wydaje się zdarzyć tylko wtedy, gdy mapKit jest używany w SingleFrameApplication (z BSAF)

Aby odtworzyć blokowanie, uruchom SimpleWSDemoApp, poczekać, aż mapa jest widoczna (trwa jakiś czas, to jest pierwszy problem), a następnie użyj myszki, aby przesunąć kciuk powiększenia szybko w górę iw dół: ui jest całkowicie zablokowane. Wykonanie tego samego na prostej ramce (odniesienie na górze) ma początkowy czas oczekiwania na ładowanie, ale nigdy nie może odtworzyć blokady.

Upiorna thingy (dla mnie) jest to, co blokuje EDT, od zrzutu gwintu VisualVM:

"AWT-EventQueue-0" prio=6 tid=0x063d3000 nid=0x1468 waiting for monitor entry [0x05efe000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at java.security.Permissions.implies(Unknown Source) 
    - waiting to lock <0x29f7b118> (a java.security.Permissions) 
    at sun.security.provider.PolicyFile.implies(Unknown Source) 
    at java.security.ProtectionDomain.implies(Unknown Source) 
    at java.security.AccessControlContext.checkPermission(Unknown Source) 
    at java.security.AccessController.checkPermission(Unknown Source) 
    at java.lang.SecurityManager.checkPermission(Unknown Source) 
    at java.lang.SecurityManager.checkSystemClipboardAccess(Unknown Source) 
    at java.awt.event.InputEvent.canAccessSystemClipboard(Unknown Source) 
    at java.awt.event.InputEvent.<init>(Unknown Source) 
    at java.awt.event.MouseEvent.<init>(Unknown Source) 
    at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) 
    at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) 
    at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) 
    at java.awt.Container.dispatchEventImpl(Unknown Source) 
    at java.awt.Window.dispatchEventImpl(Unknown Source) 
    at java.awt.Component.dispatchEvent(Unknown Source) 
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source) 
    at java.awt.EventQueue.access$200(Unknown Source) 
    at java.awt.EventQueue$3.run(Unknown Source) 
    at java.awt.EventQueue$3.run(Unknown Source) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source) 
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source) 
    at java.awt.EventQueue$4.run(Unknown Source) 
    at java.awt.EventQueue$4.run(Unknown Source) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source) 

że jest przeciągnięcie kopnięć myszy na sprawdzeniu uprawnienia do schowka dostępem ...

Answer 1

Aplikacja Web Start jest również procesem JVM, więc możesz spróbować profilować go za pomocą VisualVM (ten wpis opisuje, jak to zrobić). Warto również profilować obie aplikacje za pomocą VisualVM i porównywać ustawienia JVM, takie jak rozmiar sterty, różnice kompilacji JIT. Myślę, że aplikacja Web Start działa z kompilatorem klienta, który jest wolniejszy za pomocą produkowanego kodu natywnego niż kompilator serwera.