Issue 114102

Summary:

Performance on Print dialog: open time depends on printer dpi and document complexity

Product:

General

Reporter:

lars.langhans

Component:

chart

Assignee:

AOO issues mailing list <issues>

Status:

CONFIRMED ---

QA Contact:

Severity:

Trivial

Priority:

CC:

Armin.Le.Grand, IngridvdM, issues

Version:

3.3.0 or older (OOo)

Target Milestone:

---

Hardware:

All

OS:

Windows, all

Issue Type:

DEFECT

Latest Confirmation in:

---

Developer Difficulty:

---

Attachments:

Description	Flags
simple 3D chart demonstration	none

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.