Hash collisions in SVG loader

[lmdsp]

The picture loader in tvgLoader.cpp uses this 'hash' function:

uint64_t HASH_KEY(const char* data, uint64_t size)
{
    return (((uint64_t) data) << 32) | size;
}

static LoadModule* _findFromCache(const char* data, uint32_t size, const string& mimeType)
{
    // ...
    auto loader = _activeLoaders.head;

    auto key = HASH_KEY(data, size);

    while (loader) {
        if (loader->type == type && loader->hashkey == key) {

I'm not sure what the intended effect was, but this doesn't hash the image (svg or other) data at all.
It will only work for example if the user loads data from static const char* buffers.

We ran into this problem when attempting to load two svgs that only differ by their opacity value from an buffer external which turns out stayed had the same adress (but obviously different contents).
This is extremely confusing as their is no mention of this behavior in the Picture::load() documentation.

This can easily be fixed by using a real hash function that hashes the full data contents.
In our internal fork we replaced this with XXH3 (BSD) which is probably the fastest hash implementation out there (31Gb/s) and of great quality (low collision rate).

While I understand it might not be feasible to rely on this library for various reasons,
IMHO their should be away to customize the hash function ThorVG uses, either by passing a function pointer or through the use of a macro/define.

To entirely avoid any potential collisions, one could also do a memcmp of the data when hash keys and size are identical.

[hermet]

@lmdsp thanks for reporting & suggestion. We will look into this soon.

[hermet]

In our internal fork we replaced this with XXH3 (BSD) which is probably the fastest hash implementation out there (31Gb/s) and of great quality (low collision rate).

ps. ThorVG welcomes contributions offering better solutions.

[hermet]

After this change, ThorVG does not cache data when picture data is copied.
In fact, employing a complex caching mechanism here is not proper,
As in most cases, user would not expect the caching with the data copying.

#2026

[hermet]

the fix will be applied in 0.12.7