Thanks for the hints.  I did a bit more digging, and the image fetching is 
actually happening after the Application::addOpenedDocument call completes.  
The vast majority of time is being spent in the initial call to the 
RootGadget's layout method.
 
I did some timing tests on a small document that has 30 images and 23 seconds 
were spend in the RootGadget's layout method on the initial call.  Since I'm 
using my own custom gadget for figures, I created a buffered image on the 
client side to eliminate image fetching from the timing.  When I did this, the 
time in RootGadget's layout dropped to 2 seconds (on my old linux machine).  So 
this confirmed my suspicion that the image fetching latency was the killer.
 
I was planning on opening a dialog that shows an indeterminate progress bar 
upon the first call to the RootGadget's layout method.  When this method 
completes, I would close the dialog.  The only way that I've found to get to 
the RootGadget's layout method without modifying XXE code is by adding the 
following to my existing Application subclass:
 
   @Override
   public Editor createEditor() {
     return new Editor(this) {
       @Override
       public StyledDocumentPane createStyledDocumentPane() {
         return new StyledDocumentPane() {
           @Override
           protected RootGadget createRootGadget() {
             return new StyledDocumentView(this) {
               boolean hasBeenLayedOut = false;
               @Override
               public void layout(int constrainedWidth, int constrainedHeight) {
                 long timestart = 0;
                 if(!hasBeenLayedOut) {
                   System.err.println("laying out view ... ");  // this is 
where I would open a progress dialog
                   timestart = System.currentTimeMillis();
                 }
                 super.layout(constrainedWidth, constrainedHeight);
                 if(!hasBeenLayedOut) {
                   hasBeenLayedOut = true;
                   long currentTime = System.currentTimeMillis();
                   float seconds = (currentTime - timestart)/1000.0f;
                   System.err.println("done laying out view in "+seconds+" s"); 
// close progress dialog
                 }
               }
             };
           }
         };
       }
     };
   }
 
 
I know the code itself is ugly, but I hate to create four more classes just to 
add special behavior to the RootGadget's layout method.  Can you immediately 
see any better approach?  Am I missing something obvious?
 
 
Cheers,
Mike
 
 

________________________________

From: Hussein Shafie [mailto:[email protected]]
Sent: Fri 12/28/2007 10:08 AM
To: Santy, Michael
Cc: xmleditor-support at xmlmind.com
Subject: Re: [XXE] XXE responsiveness during file loading



Santy, Michael wrote:
> I'm able to reproduce the numbers that you are seeing when editing a
> document locally.  The issue appears to be with the latency in
> fetching remote images.  XXE, even with all of my customizations, is
> smokin' fast.
> 
> Like you said, our architecture is based around web start and every
> document is loaded into a new editor.  We've also disabled the schema
> cache.  So I expect XXE to take a few seconds to load.  XXE, up to the
> point where the document view is being created, is great about reporting
> the status of loading.
> 
> Once the document is loaded and validated, XXE starts building the
> view.  For each figure, it has to issue a request and wait for the
> response.  The fetching of images appears to be happening sequentially
> on a single thread.  If you multiply this latency by a few dozen images,
> the time starts to add up.  During this process, there is no status
> reported to the user.
> 
> I would like to show an indeterminate progress bar while the initial
> document view is being built, because this process can take several
> seconds.  Are there any events that are fired before and after the
> initial document view is built?
> 

No.

--> The document view is built during the invocation of
DocumentView.setDocument(Document). See
http://www.xmlmind.com/xmleditor/_distrib/doc/api/com/xmlmind/xmledit/view/DocumentView.html#setDocument(com.xmlmind.xmledit.doc.Document)

--> At a higher level, this happens during the invocation of
Editor.open(OpenedDocument, StyleSheetInfo). See
http://www.xmlmind.com/xmleditor/_distrib/doc/api/com/xmlmind/xmleditapp/kit/Editor.html#open(com.xmlmind.xmleditapp.kit.OpenedDocument,%20com.xmlmind.xmledit.edit.StyleSheetInfo)

     public void open(OpenedDocument openedDoc,
                      StyleSheetInfo styleSheetInfo) {
         this.openedDoc = openedDoc;
         this.styleSheetInfo = styleSheetInfo;

         configureDocumentView();
         docView.setDocument(openedDoc.getDocument());
     }

--> This open() method is invoked in com.xmlmind.xmleditapp.app.Application

     public void addOpenedDocument(OpenedDocument openedDoc) {
         ...
         for (int i = 0; i < panes.length; ++i) {
             WindowLayoutInfo.Pane pane = panes[i];

             Editor editor = createEditor();
             editor.open(openedDoc, pane.getStyleSheetInfo());
             newEditors[i] = editor;

             addingEditor(editor);
         ...
     }


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.xmlmind.com/pipermail/xmleditor-support/attachments/20071228/98876114/attachment.htm
 

Reply via email to