Change the buffer limit to depend on image size

[Archomeda]

Allocating 8KB is enough for 32x32 cursors, most of the time only 4KB will used anyway. However, when using larger cursors, 8KB isn't enough to make sure that the hash is unique. Only the first 8KB is hashed, and sometimes these pixels are the same for different cursors and YoloMouse will see them as the same.

As an example, recently Guild Wars 2 has been updated to support DPI scaling. Higher DPI settings will make use of larger cursors that are different from the normal ones, and they scale from 32x32 to 128x128. Starting from 96x96 there are a few cursors that only have transparent pixels in the first 8KB.

This PR changes the fixed 8KB to a dynamic number. It tries to determine the used bytes by multiplying the image width in bytes with the image height.

[PandaTeemo]

Hi, thanks for this update. The reason a fixed sized buffer was used was just for performance assuming that if a good enough portion of the cursor bitmap was read/hashed that it would be accurate enough. But I suppose on modern CPUs that's irrelevant. I'll pull in this change + review next update. Thanks :)

…

On Thu, Oct 19, 2017 at 6:00 PM, Archomeda ***@***.***> wrote: Allocating 8KB is enough for 32x32 cursors, most of the time only 4KB will used anyway. However, when using larger cursors, 8KB isn't enough to make sure that the hash is unique. Only the first 8KB is hashed, and sometimes these pixels are the same for different cursors and YoloMouse will see them as the same. As an example, recently Guild Wars 2 has been updated to support DPI scaling. Higher DPI settings will make use of larger cursors that are different from the normal ones, and they scale from 32x32 to 128x128. Starting from 96x96 there are a few cursors that only have transparent pixels in the first 8KB. This PR changes the fixed 8KB to a dynamic number. It tries to determine the used bytes by multiplying the image width in bytes with the image height. ------------------------------ You can view, comment on, or merge this pull request online at: #9 Commit Summary - Change the buffer limit to depend on image size File Changes - *M* source/YoloMouse/Dll/HandleCache.cpp <https://github.com/PandaTeemo/YoloMouse/pull/9/files#diff-0> (28) Patch Links: - https://github.com/PandaTeemo/YoloMouse/pull/9.patch - https://github.com/PandaTeemo/YoloMouse/pull/9.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3FMZ6CdY90Y8ViYJgP3AQjc-TpZ56-ks5st_ChgaJpZM4QADhC> .

[Archomeda]

I thought as much, judging by how long YoloMouse has existed already. Personally I haven't noticed any performance loss when I was running a debug build, but of course that's just me. I don't really know how many times the hashing method is called, but looking at the method, it's not an expensive method at all thankfully. If performance is really going to be a problem for some people, I suppose a smarter system can be made that gets the hotspots and starts hashing from there and/or around it.

[PandaTeemo]

The one problem with this update is it'll invalidate everyone's existing cursor assignments with new hashes. So I'll have to think about some backwards compatibility scheme ;)

…

On Fri, Oct 20, 2017 at 12:25 AM, Archomeda ***@***.***> wrote: I thought as much, judging by how long YoloMouse has existed already. Personally I haven't noticed any performance loss when I was running a debug build, but of course that's just me. I don't really know how many times the hashing method is called, but looking at the method, it's not an expensive method at all thankfully. If performance is really going to be a problem for some people, I suppose a smarter system can be made that gets the hotspots and starts hashing from there and/or around it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3FMUl_x1q91JupCUfaD5sBRHA_Gprcks5suEr4gaJpZM4QADhC> .

[Archomeda]

Ah yes, that will happen with all cursors that are larger than 32x32. The easiest solution would be to include a version number in the .ini files, or somehow include a version number in each hash or each assignment line. That way you'll know which algorithm to use.