OpenCV Backend

[TomzivSiteaware]

Would you consider adding support to opencv as a backend? it runs X10 times faster than matplotlib and supports the same functionality (as far as I can tell).

Why didn't you use opencv to begin with?

Thanks.

[mbway]

An alternative rasterising backend would be a good idea, whether that be cairo, agg, openCV or something else.

Matplotlib was chosen initially primarily because you can draw in data units rather than in pixels. For example if your drawing consists of a single line: (100000, 100000) to (100001, 100001) then you can simply draw a line with those coordinates and matplotlib will calculate the bounds of the image for you. This is less of a concern now as ezdxf now has bounding box calculation built-in, so you can first get the bounds of the dxf document then transform all the units to pixels before rendering.

There are some other advantages of matplotlib:

• it is very powerful, being able to draw
  • with transparency
  • lines with line styles (dashed dotted etc)
  • polygons with fill styles (eg hatched)
  • polygons with holes (interior contours)
  • bezier curves
  • arbitrarily transformed text (without bundling any fonts with ezdxf) etc
• it is not a difficult requirement to fulfil as most python environments will probably have matplotlib installed in them, less likely to have pycairo or opencv etc
• it supports lossless/vector output formats pdf and svg

So overall I still think matplotlib was a good choice, but there are definitely requirements like speed that an another backend could serve better

[TomzivSiteaware]

Thank you very much for your reply.

I see now why matplotlib was used to begin with, but in my current perspective speed is a requirements, especially considering the amount of details a dxf file can contain. It currently takes me at least 5 minutes to convert a file to an image (my current goal), let alone the RAM issues with Matplotlib, which is a major drawback.

So no current future plans to expand the backend to be more speed/RAM oriented I gather...

Thanks again.

[mbway]

I don't plan on adding another backend, but if you want to it should be relatively easy to create your own. You just have to implement either BackendInterface (if you want full control) or Backend (if you want sensible defaults) in src/ezdxf/addons/drawing/backend.py

If you have to draw in pixel units you have to manage the transformation from data to pixels as I described above but other than that it shouldn't be too difficult. See BackendScaler which mostly does what you need except you need to also translate in addition to scaling.

There are a total of 8 functions that need to be implemented to get a fully functioning backend. If you care more about speed than accuracy then you don't have to handle any of the options in the Configuration that you don't want to. Also you aren't obligated to actually draw anything when you don't want to, so for example if you only care about lines you can simply write pass in draw_text, draw_point etc. If you decide to make a mostly complete backend and it works well then you could post a pull request.

Depending on your use case you could also try to reduce or split up the work. It sounds like you are dealing with very large files so perhaps it would make sense to draw each layer (or some other grouping) individually (with transparent backgrounds) and composite them afterwards if RAM is more of a limiting factor than time? If there are many small elements that aren't visible then maybe those could be filtered out before drawing which would improve the speed?

[TomzivSiteaware]

Thank you so much for the detailed reply.
I'll give it a try.
Once I have a backend up and running I'll post a pull request.