JXMapKit/-Viewer extrem langsam wie webstartbar - wo fängt man an zu graben?

Question

Ich habe gerade versucht, einige swingx-ws-Komponenten zu den gesamten Swinglab-Demos hinzuzufügen - und festgestellt, dass ein einfacher JXMapKit/-Viewer beim Laden der Kacheln im webstartable um Größenordnungen langsamer ist als beim lokalen Laden.

eher verloren, wo soll ich anfangen suchen (ui Updates scheint am EDT zu sein, obwohl vielleicht einen genaueren Blick benötigt):

• jemand anderes die verschiedenen Ladezeiten erlebt?
• irgendeinen Tipp auf was könnte der Grund sein?
• wie ein webstartable debuggen?

Der Code recht einfach ist (lokal laufen, werden Sie swingx and swingx-ws brauchen:

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); 
      } 
     }); 
    } 

} 

bearbeiten:

scheint, wie es irgendwie mit Erlaubnis verwandt ist im Web-Kontext überprüft: Profiling zeigt, dass die gesamte Verbindung Call-Stack ist anders (nicht allzu überraschend) und dauert Ewigkeiten.Aufgeben für jetzt ..

Edit 2:

Es scheint zwei getrennte Fragen zu

• die etwas längeren Zeit, die Verbindungen zum Laden der Kacheln im Sicherheitskontext zu öffnen braucht, das ist der Hotspot in JavaWebStartSecurity. checkConnect (String, int), wie @Howard bereits bemerkt.
• eine ziemlich seltsame Blockierung des EDT, das nur dann, wenn die MapKit in einem SingleFrameApplication verwendet wird, scheint zu passieren (von BSAF)

die Blockierung zu reproduzieren, die SimpleWSDemoApp läuft, warten, bis die Karte sichtbar ist (dauert einige Zeit, das ist das erste Problem) dann mit der Maus den Zoom-Daumen schnell auf und ab bewegen: Die UI ist vollständig blockiert. Dasselbe gilt für den einfachen Rahmen (die Referenz oben). Das anfängliche Laden wartet, kann aber die Blockierung nicht reproduzieren.

Das seltsame Ding (für mich) ist, was blockiert die EDT, von dem Thread-Dump von 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) 

, die bei der Prüfung der Berechtigung für Zugriff auf der Zwischenablage die Maus Tritte schleppt ...

Answer 1

Eine Web Start App ist ebenfalls ein JVM-Prozess, sodass Sie versuchen können, ein Profil mit VisualVM zu erstellen (dieser Eintrag beschreibt, wie das geht). Es lohnt sich auch, beide Anwendungen mit VisualVM zu profilieren und JVM-Einstellungen wie Heap-Größe, JIT-Compiler-Unterschiede zu vergleichen. Ich denke, dass eine Web-Start-Anwendung mit dem Client-Compiler läuft, der langsamer ist als erzeugter nativer Code als ein Server-Compiler.