getAvailablePixels returning last pixel index instead of number of available pixels

[Robert Leach]

So I just confirmed, digging deep in the bowels of the core code and by double-checking actually using a pixel ruler on my screen that the function getAvailablePixels() is returning the "height" or "width" in pixels that is a pixel index starting with the first pixel at index 0.

I believe this accounts for why some of my calculations in the past have had to be adjusted occasionally and why the smooth zoom to selection feature I was just working on exhibited erroneous behavior for selections on the bottom and right edges.

I am adjusting my current zoom code to compensate, but I think that either the function should be renamed to getMaxPixel or it should be returning a number of available pixels that is incremented 1 from the value it currently returns. I am reluctant to just add 1 to the current function because other code has probably been written to account for the value being 1 less than expected...

[Robert Leach]

I looked into this further and it's not clear-cut. It looks like it might be returning a value that is 1 off and I think this is a precision issue from a cast similar to the issue from last year involved in the weird drawing issue with the trees. It's a bit hard to track down, and will take a lot of time to completely figure out. For now, I'm going to set this aside. I've spent too long on it already.

[Srikanth Bezawada]

@hepcat72 , Which one is preferred ?

• Making the function return number of pixels + 1 and updating the code elsewhere used to -1.
• Renaming the method to getMaxPixel.

Or does this need more debugging(precision lost in casting etc as mentioned in the first comment).

[Robert Leach]

I think this may be a precision/casting issue that needs more debugging. I think that a good first step in addressing this issue would be to add some log messages which report when the value returned is the number of pixels versus the max pixel index (perhaps with a trace?). It wouldn't resolve this issue, but it might help to better define it. The log messages should probably reference this BB issue number.

[Robert Leach]

Might be difficult to determine this, since I had had to confirm it using a pixel ruler. I suppose that you need some alternate means of determining the number of pixels the matrix draws on? ... maybe?

This is definitely an effort-level: major issue.

[Robert Leach]

Possibly related to issue #287?

[Robert Leach]

Removing milestone: Coding Convention Adherence (automated comment)