Weird pixel alignment behavior

Create issue
Issue #350 resolved
Former user created an issue

Automatic migration. Original reporter: "Timo"



The widget has its left edge at 9.5 and right edge at 20.0. But the final rendered pixels are from 10.0 to 21.0, so the right edge is off by one pixel.

It's a smallish issue, but it can for example cause widgets to overlap each other when they shouldn't (e.g. ListHeaderSegments).

CEGUI version: branches/v0-7 r2487

Reproducibility: always

Comments (4)

  1. Former user Account Deleted

    Original reporter: Timo

    I just realized that the GUI system actually makes sure that widgets never get non-integer dimensions, unless you set them manually. Am I right?

    If this is the case then feel free to ignore this report. It's not very important at least from my point of view. (What I have in my project is certain GUI scaling feature that might produce arbitrary coordinates, but I can easily round them too.)

  2. Paul Turner

    First, sorry for the long delay in responding :)

    Yes, we largely try and ensure that window positions are always pixel aligned. As far as I'm aware the only way to reproduce this is to manually set some fractional offsets (I think if I were to implement UDim now, the offset would be an integer type as opposed to float).

    I will fix this issue if I can; even though it's not all that important, because experience has shown that such issues tend to re-emerge later on if not addressed :)

  3. Paul Turner

    It seems this is not so easily fixed.

    I think the core issue stems from the use of the position / size pair to describe the area. In the example from above, we have a size of 10.5, and this ends up being passed through our pixel alignment macro which spits out '11' - which is correct as far as rounding goes, however can lead to these anomalies.

    The other option would be to round down the size. This results in 'correct' values if the position part is also fractional and rounded up, but incorrect if it's a whole number (or rounded down).

    We might consider removing all rounding until sending the data for rendering a possible solution, however past experience shows this is far from satisfactory.

    Currently I can't see a viable solution, so this may end up having to be closed as 'not fixable'. I'll consider the options some more...

  4. Paul Turner

    Ok, closing this as not-fixable. The work-around is to ensure you don't use position and size together in such a way that will cause rounding.

    In fact it's probably best to ensure that offsets are always whole numbers.

  5. Log in to comment