Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Performance on Print dialog: open time depends on printer dpi and document complexity|
|Component:||chart||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||Armin.Le.Grand, IngridvdM, issues|
|Version:||3.3.0 or older (OOo)|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description lars.langhans 2010-08-25 13:53:37 UTC
Open a print dialog is a real fast think via menu, File->Print... opens in a second. Now open the attached document, it is a simple 3D chart demonstration document. Open the print dialog via File->Print..., it will took up to 2min before you see the dialog. This depends on the default printer resolution and the processor speed/architecture. - 144dpi, 16sec - 600dpi, 48sec - 1440dpi, 2min Ok the measure of this times are done on a real old Pentium 4 with 1,8GHz and 1gb RAM. But on faster machines the times are also not really good. Also, click on cancel button in the print dialog tooks up to 30sec. before the dialog is gone.
Comment 1 lars.langhans 2010-08-25 13:55:29 UTC
Created attachment 71389 [details] simple 3D chart demonstration
Comment 2 philipp.lohmann 2010-08-25 14:00:27 UTC
It may be possible to fake a lower resolution during preview, but the essential fact will not change much. Besides that I wouldn't go below 144dpi in that case either. Nevertheless the real problem is that this seems to create gigantic bitmaps. Perhaps the drawing layer should limit the maximum resolution of these.
Comment 3 Armin Le Grand 2010-09-06 11:33:02 UTC
AW: From DrawingLayer perspective, all places where Bitmaps are created are already limited (e.g. 3D scenes) and deinable using the internal office settings. In general it is no solution to reduce the DPI; this may lead to faster responses, but You still always can construct cases where this will be slow by adding any number of complex graphic content. The general solution would be to start the dialog with a preview not showing the preview inttially, but a string saying e.g. 'preview being prepared...' or something. The preview itself should be created and shown asyncroniously when the dialog is up and running. This would not be visible for fast previews and a good way for slow ones. This would also allow the standard case (the user presses return without looking at the preview at all) to be fast. This is also already used in the PagePane, the SlideSorter and in the Impress wizards for new presentations. HTH!
Comment 4 Rob Weir 2013-07-30 02:14:10 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.