SVG graphic performance

Please post all questions and comments regarding Help & Manual 7 here.

Moderators: Alexander Halser, Tim Green

simon harris
Posts: 30
Joined: Thu Jul 26, 2018 1:35 am
Location: syd - AU

SVG graphic performance

Unread post by simon harris »

Hi Tim and Alexander,

I am using SVG format as a means of getting mechanical drawings (DWF format) into H&M that are also properly zoomable in PDF and HTML outputs. The process is a bit convoluted [print from Inventor viewer to PDF, open PDF in Illustator and export as SVG], but works. The thing is, when it comes to opening topics that contain SVGs, H&M is really slow. I understand that there is probably some heavy processing involved, but I am concerned - I have a project to start that contains over 300 drawings and am concerned that it is going to be unworkable. Do you have any advice? When it comes to zoomability and printing, I want to be able to have users print the drawings at A2 size without line degradation. I tried OLE to the PDFs, but that seems to cause H&M stability issues.

Thanks kindly and all the best,
Simon
All the best,
Simon
Simon_Dismore
Posts: 205
Joined: Thu Jul 13, 2017 2:57 pm

Re: SVG graphic performance

Unread post by Simon_Dismore »

simon harris wrote:H&M is really slow opening topics that contain SVGs
It might help Tim & Alexander if you could post a link to one of your SVG files.

Have you tried checking the SVG file that Illustrator exports? How big is it? Are any issues found by the W3 checker or the WikiMedia checker?
simon harris
Posts: 30
Joined: Thu Jul 26, 2018 1:35 am
Location: syd - AU

Re: SVG graphic performance

Unread post by simon harris »

Hi Simon,

Sizes vary from a cuppla hundred kb to maybe 3 meg that I have seen so far. I checked a few files using the w3 checker [thanks for the links] and they "pass". I can't post a link unfortunately or attach an SVG or txt file here.

All the best,
Simon
All the best,
Simon
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: SVG graphic performance

Unread post by Tim Green »

Hi Simon,

The "problem" with SVG is also its strength: An SVG file isn't really a graphics file at all. It's a script that tells an SVG interpreter how to draw a graphic. (Try opening an SVG in a code editor like Notepad++ or even regular Notepad) So when you open an SVG graphic Help+Manual needs to process the entire script and render it as graphics on the screen. This is a lot of work, and complex SVGs can easily tax a computer to its limits and beyond.

I'm going to ask Alex to chime in on this, but because of the simple mechanics of how SVGs work there is probably not a lot that can be done here. One thing that is essential, however, is to not use single-file .hmxz projects. Always use uncompressed .hmxp for things like this, and also for any larger ongoing projects. When you open an HMXZ the entire project needs to be unpacked into memory, whereas with a HMXP you are just reading a single plain-text XML topic file at a time, which generates less overheads. (Well, it's not quite that simple, but you get the general idea...)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Simon_Dismore
Posts: 205
Joined: Thu Jul 13, 2017 2:57 pm

Re: SVG graphic performance

Unread post by Simon_Dismore »

simon harris wrote:Sizes vary ...to maybe 3 meg that I have seen so far.
Tim's point about HMXZ might be all you need right now, but it would make sense to try reducing the SVG file sizes too.

There's a tool called SVGO that can reduce SVG file sizes. You might want to check that out. Jake Archibald hosts an online version he calls SVGO's missing GUI (SVGOMG).

You probably already know this, but some of the reasons Illustrator exports large SVGs are avoidable, e.g.:
  • Invisible layers that contain unnecessary detail. I don't suppose that's likely to survive your workflow, but might be worth checking.
  • Fonts being converted to outlines. There can be a lot of annotations on technical drawings, and it would probably be perfectly acceptable to render all of them in just one or two weights of a single typeface. To see what fonts are used in an Illustrator document and replace them with others, see these instructions. You'll want to use either a system font that everyone has, or a custom font you can put on your web server in the usual WOFF etc formats. Exporting as SVG fonts is deprecated nowadays, see this discussion.
  • Including unnecessary meta data ('Preserve Illustrator Editing Capabilities'). Always clear this checkbox when exporting SVGs for use with H&M. There's a good write up in this Creative Droplets article.
  • Choice of how CSS properties are applies to elements. This involves a trade-off between size and compatibility. Item 5 in this article explains the differences, but you'd have to experiment with H&M and your target browser versions to find the best setting. 'Presentation attributes' is safest, I think.
  • Having too many decimal places in coordinates. One or two is all you'll need.
Illustrator-export-SVG-advanced-options.png
You do not have the required permissions to view the files attached to this post.
User avatar
Alexander Halser
EC-Software Support
Posts: 4098
Joined: Mon Jun 24, 2002 7:24 pm
Location: Salzburg, Austria
Contact:

Re: SVG graphic performance

Unread post by Alexander Halser »

I second the suggestions to try to reduce the SVG size.

The rendering engine in Help+Manual is native, that is, we have the source code and can let it do what we need. There might by faster renderers, but if that is an external black box, it doesn't help. We need to translate SVG drawing commands into PDF drawing commands when we export PDF. Otherwise you'd get a huge bitmap instead, that doesn't scale. The rendering engine already caches the SVG images as bitmaps for display - it renders the SVG image(s) when you load the topic, but when the topic is scrolled up/down, the SVG images are quickly re-displayed from a cache bitmap. However, this also implies that all SVGs in a topic need to be rendered when the topic is loaded.
Alexander Halser
Senior Software Architect, EC Software GmbH
simon harris
Posts: 30
Joined: Thu Jul 26, 2018 1:35 am
Location: syd - AU

Re: SVG graphic performance

Unread post by simon harris »

Gentlemen,

Thanks for all your suggestions. I think that with what is potentially at stake and the sheer number of files and convoluted workflows involved that I may just opt for PNG at 300dpi. This format gives "good enough" zoom and print in PDF and the files sizes and loading times are miles better than SVG, from my limited testing. I did try all minimalist options for SVG, but saw no noticeable difference in size or handling in H&M and I understand the processing required to render images in H&M. Perhaps an option to NOT render images in the H&M editor might make a difference here or with projects that are heavy on complex or large graphics [a "draft mode", if you will].

I did also try "OLE" the PDFs directly [this is actually the ideal solution for me] but H&M did not like that particularly well and was regularly saying a big fat no to my efforts and calling it a day :? . Have a good weekend.

All the best,
Simon
All the best,
Simon
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: SVG graphic performance

Unread post by Tim Green »

Hi Simon,

Background: Note that SVG rendering is processor only, since it's a script that's being run through an interpreter. The graphics card doesn't help with it (well, there are some solutions on mobile phones that can, but that's beside the point here). Also, as far as I know, SVG rendering is handled by a single thread, so a multicore processor doesn't help either. The only thing that improves it is more single-core performance, and with all the bug fixes in current processors making that slower and slower at the moment that isn't going to be coming in the near future.

SVG is a little like web fonts: Wonderful and revolutionary in principle, but there are a lot of buts... :roll:
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: SVG graphic performance

Unread post by Martin Wynne »

simon harris wrote:I am using SVG format as a means of getting mechanical drawings (DWF format) into H&M that are also properly zoomable in PDF and HTML outputs.
Hi Simon,

Have you considered using EMF metafile format instead of SVG? Many CAD programs can export drawings to EMF. It's a vector format and zooms perfectly in the H&M editor and in the PDF output (I'm using PDF-XChange Viewer). I create them at 600dpi and insert them scaled to 100% page width.

HTML performance is more variable, depending on the browser. Firefox invites you to open them in some other application, for which I recommend IrfanView (free).

Martin.
Ethan Peart
Posts: 1
Joined: Wed Sep 12, 2018 8:44 am

Re: SVG graphic performance

Unread post by Ethan Peart »

Tim Green wrote: Fri Sep 07, 2018 9:01 am Hi Simon,

Background: Note that these are the best probiotics for women and rendering is processor only, since it's a script that's being run through an interpreter. The graphics card doesn't help with it (well, there are some solutions on mobile phones that can, but that's beside the point here). Also, as far as I know, SVG rendering is handled by a single thread, so a multicore processor doesn't help either. The only thing that improves it is more single-core performance, and with all the bug fixes in current processors making that slower and slower at the moment that isn't going to be coming in the near future.

SVG is a little like web fonts: Wonderful and revolutionary in principle, but there are a lot of buts... :roll:
Hi Martin, is EMF metafile format more complicated to work though? Or am I way off when it comes to that?
Last edited by Ethan Peart on Thu Nov 10, 2022 4:28 pm, edited 2 times in total.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: SVG graphic performance

Unread post by Martin Wynne »

Ethan Peart wrote:Hi Martin, is EMF metafile format more complicated to work though?
Hi Ethan,

Can you clarify what you mean by "complicated to work"? It is just the same as any other image -- you export/save as a file in EMF format from your application, and then insert it as an image in H&M.

It's not going to be much use in documenting a business-type application. The original question in this topic was about technical drawings from CAD-type drawing applications. Most such applications can export EMF files. The great advantage is that as a vector image format it remains crisp for line graphics at any zoom level.

Here for example I exported an EMF file at 600dpi from my application. The actual size at that dpi is 2980 pixels wide. I have inserted it in the H&M editor at 100% page width. Even though I have set the window very narrow, the EMF image remains crisp*. Compare with the PNG image above it which has become fuzzy and illegible, see:
hm_test_emf1.png
Setting a wider editor window it is still crisp:
hm_test_emf2.png
When published to PDF it is still crisp, even when enlarged to 300%:
hm_test_emf3.png
Which means that if the user wished to print it, at say 300dpi, it would be a good crisp printed drawing 10 inches / 250mm wide.

If you want to try using this EMF file as a test, you can download it from:

http://85a.co.uk/dummy/test_emf_image.emf

*crisp assuming you are viewing this with your browser set at dot-for-dot actual-size zoom level. With modern hi-res screens that's becoming a battle of wits to avoid everything going fuzzy. Using Firefox at 120dpi I set everything to 80% zoom to be sure of seeing images properly.

cheers,

Martin.
You do not have the required permissions to view the files attached to this post.
simon harris
Posts: 30
Joined: Thu Jul 26, 2018 1:35 am
Location: syd - AU

Re: SVG graphic performance

Unread post by simon harris »

Hi Martin,

Thanks for the suggestion. Sadly, the tools I have to play with do not support EMF directly. Some of the drawings in question also contain many thousands of objects, so maintaining the vector format, although ultimately the most desirable, may present other problems such as bloat and crashes. My erring for PNG is not choice but necessity, and with a bit of a safety factor built in [that is, it may be the least likely format to kill the software :shock: ]
All the best,
Simon
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: SVG graphic performance

Unread post by Tim Green »

simon harris wrote:Some of the drawings in question also contain many thousands of objects, so maintaining the vector format, although ultimately the most desirable, may present other problems such as bloat and crashes.
That is definitely not something you want to have as an active vector image on a web page. :? Even for a powerful computer it would be difficult, but most computers will still have pretty average processing power and that would probably cause unacceptable delays, at the very least. All those thousands of objects need to be rendered in real time when the image is displayed or resized... :wink:
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: SVG graphic performance

Unread post by Martin Wynne »

Tim Green wrote:All those thousands of objects need to be rendered in real time when the image is displayed or resized...
Hi Tim,

In practice I have found vector rendering much faster to zoom than resampling large bitmaps. Simon's original request was "When it comes to zoomability and printing, I want to be able to have users print the drawings at A2 size without line degradation" (my underline). That's just not possible with any reasonable sized raster format. At 300dpi for printing that's an image 7020 x 4950 pixels. Which will be just as slow to render as a vector format, and probably a larger file to download.

The best option is probably to have a small PNG on the page to view, which when clicked downloads a vector file for printing. But with 300 drawings to prepare that's going to be a lot of work.

PDF is fine for vector images. I create single-page PDF drawings typically 30ft (10 metres) long for wide-format roll-paper printing. The files are small (if they don't contain any bitmaps), download fast and open and zoom on screen without any problems in any PDF reader (except Adobe, which is the worst PDF reader and limited to a maximum page length of about 12ft / 4 metres). If you are wondering why anyone needs drawings so long, they are for railway track.

cheers,

Martin.
Simon_Dismore
Posts: 205
Joined: Thu Jul 13, 2017 2:57 pm

Re: SVG graphic performance

Unread post by Simon_Dismore »

Martin Wynne wrote:The best option is probably to have a small PNG on the page to view, which when clicked downloads a vector file for printing.
That's a very good suggestion Martin.
Martin Wynne wrote:But with 300 drawings to prepare that's going to be a lot of work.
I thought H&M would generate PNGs automatically if you convert the svg images to toggles. That's what it says in the expanding image toggles docs:

Using SVG images
You can also use vector-based SVG images for image toggles. The procedure is exactly the same as when you use any other image type.
The only difference is that the smaller version of the image is a PNG with alpha transparency instead of an SVG. The SVG image will only be displayed for the full size version.


I tried that briefly and couldn't get it to generate a PNG: it simply embedded the SVG as a thumbnail. If it did generate the PNG, that would be a major short-cut. There might be some minor effort to customize the pop-up lightbox so it includes a print button.
Post Reply