[Bug 693037] ximagesrc: delay image reconstruction when using DAMAGE

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=693037
  GStreamer | gst-plugins-good | git

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |bilboed at gmail.com
            Version|1.0.3                       |git
            Summary|ximagesrc works poorly when |ximagesrc: delay image
                   |using DAMAGE                |reconstruction when using
                   |                            |DAMAGE
     Ever Confirmed|0                           |1

--- Comment #2 from Edward Hervey <bilboed at gmail.com> 2013-07-19 04:55:08 UTC ---
The problem is that, while damage allows to limit the throughput from ximage
regarding updates (smaller data to read, you only get updates) ... it
reconstructs the images straight away in the source (memcpy of the whole final
size, potentially very slow)... and it does that in the same thread as the
capture. That results in missing capture of the earliest next frame.

Ideally that reconstruction should happen later (when the data is actually
being used) and the source should just send out buffers with the updated region
(and a reference to the previous frame).

With 1.x, ximagesrc could create a new type of GstMemory for that:

* Store reference to previous image (or to none if it's a full image or has
been reconstructed)
* When mapping (i.e. when someone wants to read it), reconstruct the full
output image (based on on damage data + previous image, which might end up
being recursive btw).

Maybe a bufferpool would also help with that also (keeping around common/last
image).

This would allow getting fast acquisition (from X) and allow delayed
reconstruction.

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