Hi,
I saw:
<https://core.fluendo.com/pigment/trac/browser/branches/rewrite-1/docs/design/block_diagram.png?format=raw>
And first thought this was making a lot of sense, but now that I look
at the current object files which pigment 0.1.5 builds, I'm a bit
worried:
1) GStreamer seems to be a strict requirement; it's de facto forced
into the API via e.g. pgm/render/pgmrenderdrawable.h which uses
GstCaps.
2) The GStreamer dependency is not limited to a part of Pigment, or the
core, it's a dependency of $(libdir)/pigment-0.1/libpgmrendergl1.so
for example, which is supposedly "only" a GL backend; I would have
expected the GL backend to only make use of a) platform stuff such as
glib, b) PgmRender and Pgm stuff, and c) GL stuff. I suppose it's
again the usage of GstCaps in the interface causing this.
3) The Python bindings not only hardcode a dependency on GStreamer, but
they also require the Pigment GStreamer plugin (pgm/form/stream.py
does a:
gst.plugin_load_file('$(libdir)/pigment-0.1/gstreamer/libpgmrendersink.so'))
Perhaps it's the schema being out-of-date, but I certainly preferred
the architectural choices the schema suggested than the currently
dependencies. :-/
Do the above critics make some sense to you? Is Pigment's development
roadmap in the direction of fixing these? Or will GStreamer become
part of the accepted "platform dependencies" of Pigment?
I currently decided to ship libpgmrendersink with the Python bindings
for Pigment as I don't know of anything else using this private
GStreamer plugin; does this sound correct? Do you plan to make use of
this element outside of the Python bindings? Why not make it public?
Bye,
--
Loïc Minier
