[gstreamer-bugs] [Bug 595513] Higher frame rates cause glimagesink to use excessive cpu

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=595513
  GStreamer | gst-plugins-gl | 0.10.1

Julien Isorce <julien.isorce> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien.isorce at gmail.com

--- Comment #1 from Julien Isorce <julien.isorce at gmail.com> 2009-09-17 21:10:38 UTC ---
videotestsrc has to generate the video buffers using CPU. 
If you increase the framerate then CPU will work more to generate and fill in
those buffers.
So the CPU% is increasing.

With gltestsrc the video textures are generated in hardware, that's why you got
2%.

So the main point is 15% vs 25%. Yes it should not have this difference.
I have an explanation:
When glimagesink receives a ram video buffer, it send it to the gl thread.
The gl thread is just a classic thread, and an opengl context is made current
in there only one time.
To communicate to the glthread, in order to excute opengl code in there, there
is an event loop which is running in the gl thread.
CPU is used to treat those events.

If you increase the framerate then there is more events.
More events they are, higher is the CPU.

I have the same behaviour on win32.

Well I am "working" (a long task) about reviewing this mecanism for a long
time.
Having several opengl contexts shared together. And communicates to the
glthread only for the final drawing. And avoind this communication for
uploading and filtering.

But it's not for now. I have to understand better how gstreamer works before.
Because I have some locking points at the moment, that put my ideas to the
trash.

-- 
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.