search

cppfw / svgren

:camera: SVG rendering library in C++
MIT License
206 stars 41 forks source link

Initial render very slow with protected software #82

Closed saeitsystems closed 3 years ago

saeitsystems commented 3 years ago

Hi Ivan, after the successful update to the new agg based library I have a Problem with the startup of my application. The software runs without problems in debug and release mode but when it gets protected with the obsidium software the render of the first image takes about 2,5 Minutes. See attached trace log.

2020-12-01 17_17_35-setIT LogViewer - TraceLog CSV - C__Users_mb_AppData_Local_SAE IT-systems_setIT This never happend with the cairo based library so I think it must be something with the agg library initialisation. I can exclude dll's from obsidium protection but svgren is linked as library...... Any Idea about the problem? Thanks for your help

igagis commented 3 years ago

I'm not familiar with obsidium, I will try to learn about it and then maybe I will get some ideas.

Some questions: What is the first image you draw? Is it complex? What if you try to draw another image as the first one, does it affect the performance?

saeitsystems commented 3 years ago

Hi Ivan, thanks again for your quick response. The first image is an icon and quite simple to render. Tomorrow I will start the application with rendering a very simple Icon and report what happens. Another approach would be to reduce or switch off compression and encryption of the app by obsidium. But this is supposed to be the job of obsidium

igagis commented 3 years ago

On the obsidium's web page I found that it supports code virtualization: https://www.obsidium.de/show/details/en

I suppose you are using it. It might slow down the performance since the code is executed by virtual machine. On the web page it says "Code Virtualization allows you to transform certain parts of your application's code". Do I understand right that by parts of the code it is meant that dll's can be excluded from virtualization? Is it possible to exclude certain functions from the main binary? If so, it might make sense to exclude svgren functions from virtualization.

The fact that only the first render is slow tells that perhaps obsidium does some code decompression/decryption at that step and then the rest of renders are fast since the code is already decompressed/decrypted.

Can you 'open up' the cSVGimage::GetCxImage function in your profiler to see in details functions that it calls and how much time is spend in each of those sub-calls? If you could identify the most lower level function which takes the most of the time it might help in understanding why it happens.

The strange thing here is that, as you say, there was no such problem with cairo. AGG does not do anything special in comparison to cairo. Are you sure that there was no any other changes to obsidium configuration since you updated to AGG-based libs?

saeitsystems commented 3 years ago

Hi Ivan, Thank you very much for your help in your free time. I will investigate tomorrow about the aspects you mentioned. The Problem firstly appeared after the upgrade to the new agg based library. It needed some time to recognise the problem because it only appears with the protected version. I have to exclude the BCGPRO mfc extension library from the protection because otherwise the application crashes on simple things. I can ask the developer of obsidium for help as well.

igagis commented 3 years ago

Is this BCGPRO mfc extension library a dll or static library?

And you are welcome! I'm developing my stuff on github in my free time anyway ;)

saeitsystems commented 3 years ago

The BCG Pro Library is in an dll and is excluded from the obsidium protection. One way to handle the problem could be to move all the svgren code to the BCGPRO dll or to a separate dll which could get excluded than as well .......

igagis commented 3 years ago

Ok, moving all the svgren stuff to a separate dll would be a simple solution which most likely works. But I think it is worth asking obsidium developer for advice, maybe it can be fixed in some simple way, since cairo version worked fine, so it might be something simple.

Let me know about your findings.

saeitsystems commented 3 years ago

Good morning, I found out that the first Icon which is rendered renders at normal speed. The second Icon causes a delay of 2,5 seconds: 2020-12-02 08_55_22-setIT LogViewer - TraceLog CSV - C__Users_mb_AppData_Local_SAE IT-systems_setIT I have attached both Icons. icon-67-192.zip The icon 192 is more complex but still simple in my opinion.

saeitsystems commented 3 years ago

Hi Ivan, after disabling the "Runtime patching" option of obsidium every thing works fine again. The application still has the encyption and compression enabled which are the more important options. From the obsidium help documentation: Runtime patching If this option is enabled, Obsidium will modify parts of your program during runtime. If you get strange program behaviour/crashes try disabling this function. This option also reduces the performance penalty caused by Runtime tracing.

Runtime tracing is still activ. As addon the application is faster now. Thanks again for your help!

igagis commented 3 years ago

Ok, good to know!

And I did not find anything strange with the icon you have attached. Yes, it is quite simple and should not cause performance problems.

Well, anyway if the problem is caused by such feature as Runtime patching it could be almost impossible to figure out how to make the obsidium happy, as it probably does a very not obvious things with that runtime patching. So, if they recommend to disable it in case of problems, it is better to follow their advice. And also then it looks like the feature is not stable and it is better not to use it in my opinion.

Good that it works for you now!