[Kdenlive-devel] Title Widget / Monitor scene speed

[Dan Dennedy]

On Sat, Aug 21, 2010 at 7:30 AM, Till Theato <root at ttill.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/21/2010 11:29 AM, Dan Dennedy wrote:
>> On Sat, Aug 21, 2010 at 1:27 AM, Simon Eugster <simon.eu at gmail.com> wrote:
>>> Regarding the title widget, I (as already stated before) vote for a
>>> rewrite anyways. Perhaps we can get rid of performance problems as
>>> well then.
>>
>> First of all, what is "monitor scene?"
>
> I use to call the monitor this way when editing geometries on it. Like
> when using Pan & Zoom and resizing the rectangle on the monitor.
> Probably not the best term for this. Any better idea?

Ah, I had become familiar with "on-monitor effects." We do need a
better way to communicate this especially with users. I am thinking
"effects editor" - could be confused with the effect parameters panel,
but this thing is just an extension of that and "editor" invokes a
more interactive tool than just some vanilla widgets. In think in most
conversation, "geometry editor" or "mask editor" will be used instead
of the more generic "effects editor."

>> Regarding a titler rewrite, I have a couple of suggestions. The window
>> needs to be more scalable than it is now - it is bigger than my screen
>> on my laptop. Also, might it be possible to make it as an overlay on
>> the clip monitor? Then, a tab sheet can contain the tools and other
>> widgets? Then, eventually, a variant of this tool can be extended as a
>> way to also use shapes/eye-dropper/wand for defining filter masks and
>> drawing into the alpha channel.
>
> Sounds like a good idea for a new titler.
>
>>
>> BTW, in thinking about masks (better term than "region"), I am
>> thinking about a way to modify MLT to allow one to place special
>> filters "Set mask" and "Apply mask" onto the filter stack. That way
>> one could designate one set of filters to apply with a mask, another
>> set with another mask, and others with no mask. The mask defined in
>> "Set mask" would be used with all filters below it and above "Apply
>> mask." And "Apply mask" clears the mask for filters below it until
>> another "Set mask." When the "Set mask" filter is selected, it could
>> expose the "mask monitor overlay widget" mentioned above.
>
> Also a very great and useful idea. Something like cheap node based
> effect editing ;)

I specifically want to avoid the topic of node-based editing. I am not
currently interested in touching upon that subject within the
framework. Some developer who really wants that may want to consider
to make a "nodal frei0r" filter that takes an XML description and
processes it entirely within a filter even though that may be
limiting.

> Starting in January 2011 I have the opportunity to write a research
> paper (correct term?) for school. I have been thinking about writing a

yes, correct term.

> MLT filter for masking using bezier curves (like masking using a
> polygon) & and a Kdenlive GUI for it. Combined with your idea this would
> be very useful.

My concept would make "Set mask" be somewhat generic and take any
producer. So, for example, the editor would be a QGraphicsScene, and
Qt can generate SVG Tiny from the drawn shapes via QSvgGenerator paint
device. That SVG would be fed into the MLT qimage producer that is
used by the mask-setter. One could also use a file made in another
tool - even a video. (Final Cut lets one drag a file from the clip bin
onto the filter's file widget.)

Other properties on the mask-setter could use image attributes instead
of a producer - for example, all pixels that fall within a hue range.
Yes, it might be nice if this selection mechanism were extensible
entirely through the other filters, but I think that crosses the line
into the territory of node-editing and my head starts hurting because
I still have to figure out how to integrate the mask with the motion
tracking stuff.

>>
>> Just some thoughts.
>>
>>> I guess what you mean is that e.g. moving objects has a delay of around 0.2 s?
>>>
>
> For me the delay is much longer 0.2 s. Maybe around 1s.

I seem to recall some interesting blog posts on the Nokia Qt site
about QGraphicsScene performance.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxv4u0ACgkQzwEyz7QP6nRlZACgwuMIDLSRh4f5s1f389Sh6/v7
> qeQAnjtejgijjgbE4X7fW6UfT+0vwFko
> =TI72
> -----END PGP SIGNATURE-----
>
-- 
+-DRD-+