[gstreamer-bugs] [Bug 600195] dynamic fragment shader filter and variables parser/loader
bugzilla at gnome.org
Thu Nov 5 07:10:06 PST 2009
GStreamer | gst-plugins-gl | git
--- Comment #5 from Filippo Argiolas <fargiolas at gnome.org> 2009-11-05 16:10:02 CET ---
Review of attachment 147010:
First of all, thanks Julien for making a real patch, it's a lot easier to
review now :)
And obviously thanks Luc for contributing back your code upstream!
I took a quick overall look at the proposed changes, didn't have the time to
test it yet but I have a few concerns.
I generally like the idea of a general purpose filter to use for shader
I'd rename it to gstglfiltershaderdebug or gstglshaderdebug or something like
this. IMHO it is only useful though, in a designing initial phase, where you
want to test different code paths and need to frequently change the shader.
When you're happy with your result you can just hardcode your shader in the new
With this use case in mind, it is really worth to ship and maintain such
complex parser code? How much uniforms did you happen to use in your shaders?
I mean if you have say up to 10-20 parameters in you shader and you want to
have them dynamically changeable at runtime you can still bind each one to a
gobject property with little effort.
What I'm trying to say is that I don't completely see the use case we are
aiming to with that parser, I see it as useful just for the designing,
That doesn't necessary mean it's not useful at all, we could include it and
enable it by default only in the uninstalled setup so that's available to
developers who wants to use it. So, I'm not refusing the patches, I'd just like
to better understand the problem they are trying to solve.
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs