[Wayland-bugs] [Bug 761312] memory leak

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761312

--- Comment #30 from Ray Strode [halfline] <rstrode at redhat.com> ---
> But won't there be scenarios where we make a almost-full frame memcopy here
> every frame even though the buffer already contained the correct pixels? If
> we ensure we have a fully drawn buffer when creating the staging buffer
> on-demand (possibly in begin_frame), we'd never need to complement after
> painting.
So my initial patch from comment 8 did the copy up front, but because of
comment 9 and discussion on IRC I changed it to do the copy afterward.

I don't quite follow what you're saying, though.  I think maybe when you say
"every frame" above you mean "every paint operation in a frame".  It's true we
do a read back at the end of each paint, when instead, we should only do it
once.

> My point being, the regular case for shm buffers is (assuming the compositor
> copies the shm buffer to the gpu and releases it immediately):
> 
> 1. draw
> 2. commit
> 3. release
> 4. frame
> 5. goto 1
> 
> If this happens, we should never need to read back at all. If we make the
> default case handle this, and create the staging buffer on demand and doing
> a full read back when doing so, we would avoid most read backs except in
> rare cases.
Right, but we could optimize the more rare case, too, which is the whole point
of doing a partial read back instead of the upfront copy I did in the first
patch. I guess, though, actually the partial read back shouldn't happen until
right before we commit the buffer, then the read back will only happen, at
most, once per frame.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20160202/6be0c748/attachment.html>