[Verse-dev] gimp plug-in hacking

[Emil Brink]

Brecht Van Lommel wrote:

> Hi,

Yo Brecht!

> I hacked the gimp sources so it can signal the plug-in on changes to
> images, to avoid it from having to diff the tiles continously.

Aha, you had to hack the GIMP to implement that, still? :/ Not your
fault of course, but still saddening that there is no such signal
or support in the GIMP core itself. After all these years, heh.

[...]
> I've also found that the plug-in isn't using the gimp interface very 
> efficiently.
> I'm coding a solution for that, but it's not yet finished. For downloading
> I'll have it keep the gimp tile references during verse_callback_update,
> so changes can be written immediate, and then flushed at the end. Should
> be more efficient than what it does now.

Aha, sounds very interesting. I'm not sure what causes the delays Toni
has measured (hours for a large image transfer), if it's the comparison,
the sending, or the reception. Or something completely different.

> Getting rid of the upload/download modes is proving to be quite difficult
> though. Basically there's a synchronization problem  that I can't figure
> out how to solve. It happens for example in this scenario (assume there is
> only one tile in the image):
> 
> - user starts painting stroke
> - gimp plug-in sends tile with contents A
> - user continues painting
> - gimp plug-in sends tile with contents B
> - user stops painting stroke
> - gimp plug-in receives tile with contents A
> - user paints over outdated tile with contents A

Ah, I see. This is (of course) a consequence of the fact the GIMP
changes the image locally, before the plug-in notices. This "vio-
lates"[*] a standard design idea when doing Verse applications,
namely that local state (such as a bitmap) should only be updated
when the server says so. That avoids ownership confusion, but is
of course not an option in the case of the GIMP.

> The only problem to this solution I can think of is that the plug-in would
> ignore it's own tiles. But there seems to be no way to do this reliable
> without the verse server telling which ones are the plug-in's own tiles.

True, I don't think that's possible, either. Except perhaps with a large
enough checksum over the tile, but that wouldn't exactly be a nice solu-
tion, and perhaps the collision rate would still be large enough to be
a problem.

> These are the only solutions I can come up with, but none of the are
> really good:
> 
> - Only send tiles after the stroke is painted. But if multiple strokes are
>    painted right after each other the problem can still occur.

Didn't know that was even possible ... Sounds like it would improve
things, but as you say still have issues. Plus, it would make it
look and feel a lot less interactive, I think.

> - Ignore incoming tiles on a specific position a few seconds after sending
>    a tile from that position. Doesn't work when there is heavy lagging,
>    and we may end up ignoring tiles from other apps, and get out of sync.

And has a lot of overhead.

> - Hack the verse server?

Yeah, this has been discussed here for a while, too. I'm not sure what
Eskil's position is, so *please* speak up, Eskil! The idea would be,
as I've understood it, to introduce a new "mode" of subscription. Any
client using the new (let's call it "weak") mode, would not have its
data sent back to it when it does a change. That's all. I think the
implementation is basically an if() in the loop that sends out a change
to all subscribers, to skip the current one if it's weak.

Eskil: would that work? If not, do you have any other suggestions
as to how application plug-in developers can get around this problem?
Asking the application to not change the data until Verse says so
is probably out. :/

Thanks for the investigation and suggestions, Brecht!

Regards,

/Emil

[*] GIMP was not designed to be a Verse application, so accusing it
     (or its plug-in API) to violate Verse "rules" would be a bit much.