position problem when drawing a CircleShape on Windows 10

[shujidev]

I am not sure but I think it's a problem with windows 10 borderless windows
The problem is when I draw the circle its always drawn with a little offset from where it should be.

top-left corner


bottom-right corner


In the top of the window the shape is drawn above the mouse, in the bottom the shape is drawn under the mouse and so for each side of the window

#include "SFML/Graphics.hpp"
#include <stdio.h>
int main(int argc, char **argv){
        sf::RenderWindow window(sf::VideoMode(800, 600), "SFML Application");
        window.setFramerateLimit(60);

        sf::RenderTexture renderTexture;
        renderTexture.create(800,600);
        renderTexture.setSmooth(true);
        renderTexture.clear(sf::Color(255,255,255,255));
        renderTexture.display();

        int wpoint=10;
        sf::CircleShape point(wpoint,50);
        point.setFillColor(sf::Color(255, 0, 0, 128));

        while(1){
                sf::Event event;
                while (window.pollEvent(event)){
                        if (event.type==sf::Event::MouseMoved && sf::Mouse::isButtonPressed(sf::Mouse::Left)){
                                //printf("%d\n",sf::Mouse::isButtonPressed(sf::Mouse::Left));
                                //point.setPosition(event.mouseMove.x-(wpoint/2),event.mouseMove.y-(wpoint/2));
                                //point.setPosition(event.mouseMove.x,event.mouseMove.y);
                                //auto pos=sf::Mouse::getPosition();
                                auto poswindow=window.getPosition();
                                printf("%d,%d\n",poswindow.x,poswindow.y); //This prints -8,0 when I position the window on the left-top corner (0,0)!!
                                //auto pos=sf::Mouse::getPosition(window);
                                auto pos=window.mapPixelToCoords(sf::Mouse::getPosition(window));
                                point.setPosition(pos.x,pos.y);
                                renderTexture.draw(point, sf::BlendAlpha);
                        }
                        if (event.type==sf::Event::Closed
                         || event.type==sf::Event::KeyPressed && event.key.code==sf::Keyboard::Escape)
                                return 0;
                }

                sf::Sprite canvas(renderTexture.getTexture());
                // draw
                window.clear();
                window.draw(canvas);
                window.display();
        }
        return 0;
}

It doesn't matter, I read somewhere that it's a thing that only happens with some Intel drivers, I just hope that the users don't have it or I will be in troubles. It's weird because I have been working with the Winapi for a long time and the mouse coordinates have always been correct.
If this is something that affects a lot of people one solution might be to add an empty window filling the ClientRect and adding the context to it, am I right?

[Hapax]

When are you calling display on the render texture?

Remember that a render texture is a render target as is a render window, which means that both require the "clear, draw, display" to be "complete". Render textures are double buffered too, aren't they?

Update the contents of the target texture.

This function updates the target texture with what has been drawn so far. Like for windows, calling this function is mandatory at the end of rendering. Not calling it may leave the texture in an undefined state.

[shujidev]

ok I did so but the problem remained the same, what I tried to do is clear and display the texture once and increment it by drawing circles into it
One thing I noticed is when I tried to draw the circle on (10,10) it was painted under the title bar.

[Hapax]

The point is that as soon as anything changes the render texture, you need to call its display method before its texture can be used.

This means that the render texture is either going to be static (set up once then not changed) or it must be cleared, drawn, and displayed every time before its texture is used.

This means that the entire rendering on the texture needs to be entirely reconstructed every time so every stage should be recorded so that it can be drawn. Note that this can remove the need for a render texture at all.

The other option is to save to an image each time the render texture changes. This is slower but is maybe a better idea for this sort of work. You can draw the current image to a render texture, draw the new part to the render texture and then save the current state of the render texture to the image (each time it changes). You can probably see why it's slower. If you are able to manipulate the image directly to add parts to it (instead of rendering "circles", you manipulate image's data to add a rectangular sprite, for example), that could increase its speed further.

One thing to consider is that you can compromise slightly during the first option above in that you can "snapshot" the current state of drawing to a render texture "every so often". That is, while recording what to draw each time, you can draw a batch of them so far to a render texture, and then draw the rest directly to the window after the render texture. You can then draw the render texture and the new batch to a second render texture and use that as the base for drawing to the window et cetera.

Most important thing to remember here is that a render texture must be cleared, drawn entirely, and displayed any time it is changed.

[Laurent]

The other option is to save to an image each time the render texture changes.

Or to another render texture (kind of double buffering) to avoid data transfers back to the CPU.