Out of memory ?!

[Nicolae Trifu]

Out of memory - very often lately, with Xpro 4.0.4966, exporting large PNGs.

I re-installed X3.0, in frustration, and it had no error while X4 still did !

Dual Xeon 3.8, Server 2003 PAE, 8GB RAM, 4 OS + 4 RamDisk, total paging file 2046MB. Xara, of course, only uses 2 GB.

I do very large drawings, 7200x4800, with many layers - Architecture. I import and create a lot of pngs, mould them, then again convert or export out to PNG. They easily get to 8,000 - 10,000 pixels wide. I do need this sharpness, so no talk of going around it. ( see http://site.xara.com/news/february07...ationalart.asp )

JPGs export without problem to 14,000. Out of memory starts popping up as I make more and more large PNGs, mould, convert them to bitmap, cut, etc, then export to PNG. Even seen some Access violations.

Very subjectively, I would say that I do not remember having to fight this in X 3.0 - X 3.2, early X 4.0.

Help ?

[steve.ledger]

I am getting this often as well. Very annoying when I need large bitmaps.
I normally quit to CorelDRAW and export large bitmaps from there.

I'm interested in your comment "Xara, of course, only uses 2 GB" ??

[willdean]

I'm interested in your comment "Xara, of course, only uses 2 GB" ??

Ordinary 32-bit apps running on 32-bit Windows only have 2GB of address space available to them (the other 2G of the total address space is allocated to the system. There are ways to change the split to 3:1 rather than 2:2, but they were really a stop-gap on the way to 64-bit.

To get the 3:1 stuff to work, you need to change both the application and the Windows startup file - I don't know if Xara is configured in this way, and I think software vendors rather shy away from asking end-users to modify their Windows startup files...

One day there will be a 64-bit version of Xara, and even Nicolae will struggle to exhaust the address space then!

[steve.ledger]

Yes, but how does this relate to this version of Xara.

[Nicolae Trifu]

I'm interested in your comment "Xara, of course, only uses 2 GB" ??

Options / Tune-ups / Cache control - always shows 2,047 M ( meant by "of course" ).

Yes all 32bit apps have a box to play in, but some of them try harder.

As my Xara is not impressed with a fast / large temp.file, and as the memory error is more present on some versions than on others, and as "Charles " recently posted having cured it, and as this is my software of choice ...

I am asking for a (better) cure.

[steve.ledger]

Options / Tune-ups / Cache control - always shows 2,047 M ( meant by "of course" ).

As you've seen, cache control is new to version 4.
The amount of memory used when working with a doc is dependent on the complexity and use of , groups, bevels, shadows, blends, molds, contours, ClipViews and Live Effects.
It should not 'always show 2,047M' - even if you have set the percentage to use at 100%.

When I resize to export very large JPG photos, this figure remains at zero.
Though I still get the 'Out Of Memory' error inspite of caching not being used.

I do not believe that this is the problem.
I do believe part of the problem has something to do with the Xara internal restriction of 9ft (2.74m) sizes (which should be fixed..!)

[Xhris]

Caching has been used in Xara since version 2 actually. It is used to speed up rendering in various ways, and is highly unlikely to be even indirectly related to the problem mentioned here like you say Steve.

[steve.ledger]

You're quite right Xhris, my mistake - I simply checked the Xtreme4 help file for further information and read the passage there which indicates it was new to version 4.

Cache Control
Xara Xtreme Pro 4 includes powerful caching support that was not available in any earlier versions of the application. Complex objects including layers, groups, bevels, shadows, blends, molds, contours, ClipViews and Live Effects can be cached as bitmaps when they are rendered. This means that the next time these objects need to be redrawn, the bitmap can often be used instead of re-rendering the objects, making redraws and object drags very much faster. The difference is particularly noticeable with complex documents.

Obviously the updating of the help file wasn't thoroughly checked for errors