Apache OpenOffice (AOO) Bugzilla – Issue 18883
Printing through c++ bridge takes much longer then through COM/Basic
Last modified: 2004-09-27 11:20:44 UTC
When trying to print a document throght the C++-bridge I found that the "print" will need to return some seconds. The blue bar indicating the print-progress is very much slower then when printing throught COM, Basic or directly with the print button from the user-interface. I made a sample-project with VC++ 6.0 to show the difference. It has 2 buttons which just loads a document and then prints it - without any parameters or listeners or something. It displays a MessageBox how long it took the print to return. On my computer it's 0 seconds for the COM and 3 seconds for the Bridge to return from the print with the attached Test.swx. It seems to depend on the size of the document to be print, I got a more complex 3-page-document (with tables, pics and rows), which takes COM: 1 sec, Bridge: 37 sec. Please change the pathes and files at the top of OOPrintTestDlg.cpp and in Debug/OOPrintTestDlg.ini to suite your environment.
Created attachment 8917 [details] VC++-Project which prints through COM and through the Bridge
Created attachment 8918 [details] 3-Page-Test-Document (Text, 2 Pics)
implementation issue
AS->Daniel: Sorry - but I think you dont measure the time for printing here. Your test measure the time, which is needed to call the remote interface and return back from there. The implementation behind this interface is everytimes the same, the printed document isnt changed => so the time needed for printing (which is done inside the remote office proccess and not inside your client application) must be the same. No data of the printing document are transfered due to the bridge! And as you already know from #i14397#: calling of XPrintable.print() without any special parameter starts the print job as an asynchronous process ... and the interface call returns immediatly after printing was started. I suggest, that marshalling due to the C++ bridge is slower then due to the COM bridge. And further ... NO this bug isnt related to #i14397#! Because there you describe the problem with an asynchronous print job in relation to closing the document, which is a multithreading issue. AS->DBO: I guess - its your ...
Hi Andreas, thanx for your reply. You are right that I'm measuring the time between the call and the return of the call. But I have 2 arguments that it's not the call which makes the different: 1.) In general "early binding" (C++-Call) is faster then a "late binding" (COM-call). I've tested several other funtions where this is always true. So I think, a delay of 37 sec can't be explained as only "time for mashalling". 2.) The blue progress bar really is slower when the call is invoked from C++ then from COM. Because this could be only meassured subjectivly, I showed a view other people the progress bar - all of them said that the bar progresses much slower when the C++-call is used. I, too, have to explanaition for this.
@ssa: as commincated by kso to you...
reassigned.
KSO->SSA: Just investiagted a little into the problem. First, yes, it's reproducable. The big difference is that when using COM the print() UNO method gets always called from within the main thread of the Office process and when using the URP (C++) bridge the method always gets called from another thread (not-main). Looking at vcl/win/source/app/slainst.cxx -> SalInstance::Yield() I found a Sleep(1) in case we're not in the main thread. I removed this (only for testing) and ... printing time did not differ anymore!
The sleep during yield which is called from a thread different to the main thread was required to get rid of a dead lock that was triggered by trying to switch to the busy main thread by sending a message. I'll try to detect this situation and sleep only when the the main thread is busy, this should cure the performance problem.
Changed target milestone.
The (time-consuming) sleep call is now only used when the deadlock scenario is given, ie, when there is already a yielding dialog that might block the main thread.
Thanx for the fast fixing!
ssa->kso: please verify.
Looks good.
... and VERIFIED.
Martin, you should close this issue after verifiying that the fix works for you in OOo 1.1.1
-> Ack
Setting from KSO are not taken.
Set to Verified.
close issue.