Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sf::RenderTarget::display() not present?  (Read 7528 times)

0 Members and 2 Guests are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: sf::RenderTarget::display() not present?
« Reply #15 on: March 19, 2018, 08:17:44 am »
And what I said above is that the call to display() should not be part of the drawing process.

    auto draw = [&sprite, &currentTarget]()
    {
        currentTarget->clear();
        currentTarget->draw(sprite);
    }

    // ...

        draw();
        if (!use_window)
        {
            buffer.display();
            window.clear();
            window.draw(bufferSprite);
        }
        window.display();

Because display is not directly related to drawing, it's rather about what you do of your pixel buffer once drawing is done.

Quote
Furthermore, Why don't the reasons (of which there haven't really been any clear ones...) for not doing this apply to getSize()? or setActive()?
A render target is something you can draw to. So it make sense to query its size.
And because we can draw to a render target with OpenGL calls directly, we must be able to activate its internal context, thus the reason for setActive. There will probably be no other implementation of RenderTarget in the future, but if there was, it would have to have these functions in order to be a useful render target.

On the other hand, (Render)Window::display() is not a generic operation on the render target, because what it does is to copy the content of the target to the monitor. And I can hardly see an equivalent of something related to a monitor in something that is not a window.

RenderTexture::display should really be named differently. It does not display anything, and in an ideal world it would not even be needed. But sometimes there is something to do after drawing, to ensure that everything's properly done, so I chose to use this name for consistency with windows. But now I see that this was probably an error.
« Last Edit: March 19, 2018, 08:20:08 am by Laurent »
Laurent Gomila - SFML developer