<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - memory leak" href="https://bugzilla.gnome.org/show_bug.cgi?id=761312#c49">Comment # 49</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - memory leak" href="https://bugzilla.gnome.org/show_bug.cgi?id=761312">bug 761312</a> from <a href="page.cgi?id=describeuser.html&login=jstpierre%40mecheye.net" title="Jasper St. Pierre <jstpierre@mecheye.net>"> Jasper St. Pierre</a> <pre>(In reply to Ray Strode [halfline] from <a href="show_bug.cgi?id=761312#c46">comment #46</a>) > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=761312#c45">comment #45</a>) > > I do however think that the two patches before this would be > > better squashed into this one, since the intermediate state > > isn't really an improvement (looks like we'll just always > > draw on the live buffer, but maybe I'm wrong). > Well, I split it out because the patch is kind of unwieldy. > > The cursor changes are really just a casualty of the other > code, so i'd rather it didn't get thrown into the same patch. > > Cutting out the set_busy stuff up front doesn't make the > code worse, we're already always drawing on a live buffer we > aren't supposed to. That's because the temporary buffer it > allocated in begin_paint and blitted out in end_paint, which > are always bracketed together when used, so there's no chance > a release will ever before the shared buffer is drawn to. So > i'm just cutting out broken code, and having that rescission > in the same patch as the fix makes the fix harder to follow. The theory isn't that GTK+ will receive and process a receive, it's that it will win the race and mutter will have completed the texture upload / copy by then and queued up a release by then.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>