XML Author: Chokes on Big Images?
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
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 <idiotprogrammer@gmail.com> 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 oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
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 <idiotprogrammer@gmail.com> 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 oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Hi Robert, So as Dan mentioned Oxygen should not slow down at all when editing in the Author page if the images are not present in the editor visible area. The only case in which a slow down might occur would be when editing text and having images displayed in the visible area of the Author page. You mentioned the images are scaled down, how many such scaled down images fit the visible part of the Author page? Of course, if you could zip and send to our support address a sample Docbook 5 project (+ images) it would help us better understand your situation. Regards, Radu -- Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 7/19/2010 11:42 AM, Dan Caprioara wrote:
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<idiotprogrammer@gmail.com> 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 oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
participants (4)
-
Andrew Welch -
Dan Caprioara -
Radu Coravu -
Robert Nagle