Suggestion for smarter CEGUIWindow::getHitTestRect_impl

[marvinx]

Hi,

I am currently working on a window layout that uses a custom ScrollablePane as main panel. The ScrollableContainer component of this pane uses a RenderingWindow for rendering its content to a large texture, which is then projected into ScrollablePane's view area. This allows me (amongst others) to implement a "ZoomableScrollablePane" widget, that is, the rendered ScrollContainer content (from texture target) can be displayed "zoomed-in and -out". So far so good.

When working with such a window layout there exist one special case that is not yet considered in CEGUIWindow::getHitRectTest_impl() from CEGUI-0.7.7. This case concerns a "non-ClippedByParent" window whose parent is texture-backed. For example, consider a DragContainer-based widget that can be picked-up and dragged/dropped around within the texture-backed ScrollableContainer.

For "non-ClippedByParent" windows, the default getHitRectTest_impl() will always use the screen area as "mother" for HitRect testing, and will ignore cases where a texture target is used for rendering (whose texture size is much larger then the screen area).

Below is a small patch for CEGUIWindow::getHitRectTest_impl() which specially handles the above mentioned case. This patch works fine for me (so far). However, I am not sure if it introduces odd behaviors in other parts of the library Thank in advance any comments!

Code: Select all

Rect Window::getHitTestRect_impl() const
{
    // if clipped by parent wnd, hit test area is the intersection of our
    // outer rect with the parent's hit test area intersected with the
    // parent's clipper.
    if (d_parent && d_clippedByParent)
    {
        return getUnclippedOuterRect().getIntersection(
            d_parent->getHitTestRect().getIntersection(
                d_parent->getClipRect(d_nonClientContent)));
    }

    // Added 04/27/2013, KS
    // - If our parent's mother is texture-backed, then we should
    //   intersect with the mother's ClipRect (and not with the screen area)

    else if ( d_parent && !d_clippedByParent   &&
               d_parent->getParent()   &&
               d_parent->getParent()->getRenderingSurface()  &&
               d_parent->getParent()->getRenderingSurface()->isRenderingWindow() )
    {
      const Window* const mother = d_parent->getParent();
      return getUnclippedOuterRect().getIntersection(mother->getClipRect());
    }

    // not clipped to parent wnd, so get intersection with screen area.
    else
    {
        return getUnclippedOuterRect().getIntersection(
          Rect(Vector2(0, 0), System::getSingleton().getRenderer()->getDisplaySize()));
    }
}


[CrazyEddie]

I haven't had a chance to really go into this, but will say that ideally the non-clipped by parent with a texture backed parent should actually render outside of the parent's texture, the fact that is does not is technically a bug, but there is no simple fix for that, so given this, the mod may eventually become incorrect and not work right (having said this, I see no fix on the horizon).

Anyway, as with the other topic, can you add a mantis ticket? This way we will not forget to take a closer look at it and lose a potentially valuable modification.

Thanks

CE.

[marvinx]

First of all, thanks for the reply.

ideally the non-clipped by parent with a texture backed parent should actually render outside of the parent's texture

I agree with you in that point. But what if the the parent itself is rendered to texture and not to screen? I had this case with a Drag&Drop enabled part of Widget that lives itself on a large texture-backed pane. I know that such a window configuration is not a typical use case. So my post was NOT a bug report , but just a note. BTW, the proposed patch is still working fine for me.

I will add the Mantis ticket.