[oXygen-user] XML Author: Chokes on Big Images?
Dan Caprioara
Mon Jul 19 03:42:57 CDT 2010
oXygen does not keep in memory all the images that are referred by the
document. It just holds the width and height for each one in order to
layout the document. Only when the image crosses the border of the
visible part of the document then it is read fully and stored in a cache.
Currently, oXygen has an internal cache for images that is 5MB in size.
If you images are bigger than that (the number of megapixels multiplied
with the color depth), then it is likely the images will never enter the
cache. Setting the -Xmx parameter to larger values will have no effect
on the cache size.
For version 12 we already modified the caching strategy: oXygen will
cache at least four images, disregarding their size. The size of the
cache was also increased to 10MB.
Cheers,
Dan
--
Dan Caprioara
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
Andrew Welch wrote:
> Try giving it more memory: open the "oxygen.vmoptions" file (its in
> the same place as the exe) and change
>
> -Xmx700m
>
> to
>
> -Xmx2000m
>
> Thats the amount of memory in megabytes that Java will take when you
> start Oxygen... it will never go higher than that, so thats likely to
> be the reason why you notice the slow down around 700 - 800mb.
>
> cheers
> andrew
>
>
> On 16 July 2010 19:33, Robert Nagle <> wrote:
>> Two days ago I asked a question about Oxygen's ability to process lots
>> of images. Thanks for the reply by the way with the tip about XEP.
>> I have a related question which is annoying me, and I think it is an
>> Oxygen-related question (and not an XEP question).
>>
>> In Docbook 5 I am using xincludes, and I am using 300 dpi images (with
>> dimensions ranging from 1200 x 1500 more or less). They are jpg file
>> at 100% quality and range from 600K to 1 MB. One of the files is
>> 2300x1500
>> In my Docbook 5 project I scale the image so that the size when
>> printed is about 3 inches.
>>
>> But here's the thing. After I add as few as three images to a chapter
>> (and sometimes less), XML Author pretty much grinds to a halt. The
>> chapter is an xinclude file. (I'm in Windows Vista 64 bit and have 4
>> gigs RAM, and RAM usage by Oxygen goes up to about 700,000 or 800,000
>> MB RAM. I can continue editing, but very slowly. Once I switch back to
>> XML mode, everything is fine. I have gotten no validation errors or
>> anything like that, and the xml file itself is not overly big (30 K).
>>
>> I've tried to open the same xml file on a different machine, a 64 bit
>> Windows 7 with 4 Gigs RAM. I receive the same slowdown.
>>
>> Is this typical? Do you have any suggestions about how to avoid
>> this slowdown? It's gotten so bad that I've had to comment out the
>> images until I have to produce the PDF (a real pain).
>>
>> At the moment each of my mediaobjects have 2 imageobjects. The 2nd is
>> an empty folder for a web version of the same image. If worse comes to
>> worse, I could delete this extra imageobject, but eventually I need to
>> add it.
>>
>>
>>
>> <screenshot>
>> <mediaobject>
>> <imageobject role="html">
>> <imagedata fileref="web-images/"/>
>> </imageobject>
>> <imageobject role="fo">
>> <imagedata
>> fileref="fo-images/history-byline.jpg" contentwidth="10cm"/>
>> </imageobject>
>> <textobject>
>> <phrase>.</phrase>
>> </textobject>
>> <caption>
>> <para>If your content is being versioned, you
>> will see a History hyperlink
>> near the byline. </para>
>> </caption>
>> </mediaobject>
>> </screenshot>
>>
>>
>> --
>> Robert Nagle
>> _______________________________________________
>> oXygen-user mailing list
>>
>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
>>
>
>
>
More information about the oXygen-user
mailing list