A
ABF
Hello,
I have a concern. I have created a small printing
framework and it is taking a lot of memory.
Simply put, the framework iterates through objects that
implement a "printable" interfaces. Each object provides
an image represented by a System:rawing::Image*, the
framework then "draws" these images on pages to print.
Everything is done in memory, nothing comes from disk. I
am using GDI+ classes to draw, and creating a printpreview
dialog.
e.g. by creating bitmaps for 2 full pages, the application
allocates 40 MB (2x 5M pixels at 32bpp) for each full page
(one for screen and one for printer?). I do call dispose
whenever possible.
I do not understand why the expected memory consumption is
doubled and so high. But it has to do with the internals
of System:rawing:rinting:rintDocument.
Imagine with 10+ more pages...
So is there a way to compress it this memory? Can we tell
the PrintDocument to flush it. Is there a better way
to "provide" images as parts of a bigger whole? Is there
another to construct the pages to be printed?
I tried to use indexed bitmap, but we can not create a
graphics object from it...
Or is the approach flawed in itself? Should I have created
huge editable bmp, save them as compressed file format and
only then reload them for assembly?
I am developing in managed C++ (must be accesible for C#
clients) with visual studio 2002. Note that I am
relatively new to the .net framework, although experienced
in C++.
Thanks for your help. Any idea will be appreciated!
A.
I have a concern. I have created a small printing
framework and it is taking a lot of memory.
Simply put, the framework iterates through objects that
implement a "printable" interfaces. Each object provides
an image represented by a System:rawing::Image*, the
framework then "draws" these images on pages to print.
Everything is done in memory, nothing comes from disk. I
am using GDI+ classes to draw, and creating a printpreview
dialog.
e.g. by creating bitmaps for 2 full pages, the application
allocates 40 MB (2x 5M pixels at 32bpp) for each full page
(one for screen and one for printer?). I do call dispose
whenever possible.
I do not understand why the expected memory consumption is
doubled and so high. But it has to do with the internals
of System:rawing:rinting:rintDocument.
Imagine with 10+ more pages...
So is there a way to compress it this memory? Can we tell
the PrintDocument to flush it. Is there a better way
to "provide" images as parts of a bigger whole? Is there
another to construct the pages to be printed?
I tried to use indexed bitmap, but we can not create a
graphics object from it...
Or is the approach flawed in itself? Should I have created
huge editable bmp, save them as compressed file format and
only then reload them for assembly?
I am developing in managed C++ (must be accesible for C#
clients) with visual studio 2002. Note that I am
relatively new to the .net framework, although experienced
in C++.
Thanks for your help. Any idea will be appreciated!
A.