Issue 33219 - transparent objects needs too much memory on high-res printing
Summary: transparent objects needs too much memory on high-res printing
Status: ACCEPTED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.1.2
Hardware: PC All
: P3 Trivial with 3 votes (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-19 16:33 UTC by pmladek
Modified: 2013-02-07 22:16 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
More that 1GB of memory was needed to print this document. (6.03 KB, application/vnd.sun.xml.draw)
2004-08-19 16:36 UTC, pmladek
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description pmladek 2004-08-19 16:33:50 UTC
This issue is releated to the issue #29483.

I use the patched generic PPD by the patch attached to the issue #29483. I tried
to print a document with transparent objects with the Image Rendering Resolution
set to 2400dpi. The result was that OOo nearly freezed the machine for a long of
time and needed more that 1GB of memory to finish the task.

The problem would be that OOo want's to have all information in memory and is
not able to process the page part by part.

I'll attach a document for testing.
Comment 1 pmladek 2004-08-19 16:36:36 UTC
Created attachment 17236 [details]
More that 1GB of memory was needed to print this document.
Comment 2 christof.pintaske 2004-08-23 12:01:02 UTC
cp->ka: I think we do split the image in stripes, isn't it ? please give some
details on that.
Comment 3 ooo 2004-08-23 14:24:32 UTC
I'd like to hand this task over to you, Thorsten.
Comment 4 thb 2004-08-24 11:08:03 UTC
The crucial point here is twofold: 
 - first, that OOo's print engine prepares a whole page in memory 
(generating a GDIMetaFile for it). 
 - and second, that, although some basic optimizations are 
there, OOo cannot currently optimize the case of a complex figure with a transparent gradient over 
plain background. 

Thus, OOo generates banded bitmaps for the area affected by 
transparency, and puts all those small band bitmaps into one metafile in memory. One might argue 
that a plain rectangle needn't be handled as a complex figure (aka metafile), but this is somewhat 
deeply entrenced in svx's XOutDev (apart from being a nice generic solution, except for the trouble it 
causes here).

To conclude, the way it works today is more or less 'by design', i.e. a conscious 
tradeoff between speed, application responsiveness, and memory consumption. Because of that, 
this is clearly a feature request and not a defect.

BTW, OOo _does_ optimize transparent 
printing of bitmaps, thus, replacing the rectangle with a gradient bitmap should actually perform 
much better (as long as there's nothing _behind_ that object and the white page).
Comment 5 thb 2012-07-13 20:47:50 UTC
Reset to default bug assignee.