RenderTexture ContentSize Error

[asnagni]

Hello, When trying to capture a screenshot of a ax::ui::ImageView, when I create a RenderTexture with the same size as the ImageView and then try to check the the RenderTexture size after creation, I get a zero (0) for the width and height.

You can use this image for the test (or anyone of you like):

The is the code used that exhibits the issue:

auto pImage = ax::ui::ImageView::create(“textImage.png");

if(pImage != nullptr)
{
        addChild(pImage);

        std::string strFilename(“myCaptureTextImage.png”);

        scheduleOnce([=](float)
        {
            // Get the size of the ImageView
            Size imageViewSize = imageView->getContentSize();

            AXLOG("ImageView Size - Width: %f, Height: %f", imageViewSize.width, imageViewSize.height);

            // Create a RenderTexture with the same size as the ImageView
            RenderTexture* renderTexture = RenderTexture::create(imageViewSize.width, imageViewSize.height, backend::PixelFormat::RGBA8, backend::PixelFormat::D24S8);
            renderTexture->retain();

            // Check the RenderTexture size after creation
            Size renderTextureSize = renderTexture->getContentSize();
            AXLOG("RenderTexture Size - Width: %f, Height: %f", renderTextureSize.width, renderTextureSize.height);

            // Ensure the RenderTexture is properly initialized
            if (renderTextureSize.width == 0 || renderTextureSize.height == 0) {
                AXLOG("Error: RenderTexture not properly initialized.");
                return;
            }

            // Release the RenderTexture
            renderTexture->release();

        }, 0.f, "capture_sv");
}

1) We would like to know if there is another way of getting the RenderTexture content size 2) If yes how can we do that.

Thank you for your help, Stay safe

• axmol version: 2.1.4
• devices test on: iPhone 11, 12, 14
• developing environments
  • NDK version: n/a
  • Xcode version: 15.4
  • Visual Studio: n/a
    • VS version: n/a
    • MSVC version: n/a
    • Windows SDK version: n/a
  • cmake version: 3.29.0 Steps to Reproduce:

1. create an ax::ui::ImageView object
2. Try to capture it
3. Check the RenderTexture size

[rh101]

Try renderTexture->getSprite()->getContentSize().

It is a little strange that RenderTexture content isn't set at creation, but if that were to be implemented, it may impact the positioning of the internal sprite, since it's a child of the RenderTexture. If the content size of the RenderTexture were to be set, then the position and anchor point of the internal sprite would need to be modified in order for it to be correct (and not break existing usage).

[asnagni]

@rh101 Yes, I found that very strange and I step in the code to try to figure out what was the problem but defiantly it is not working. I could find a place where the value was set.

Doing this: renderTexture->getSprite()->getContentSize() Will work but it is not intuitive and it doesn't fallow the rest the API pattern. I think this issue is not a high priority issue but it would be nice to have a clean interface. It's not intuitive to do this to get the size.

What do you think?

[rh101]

Will work but it is not intuitive and it doesn't fallow the rest the API pattern. I think this issue is not a high priority issue but it would be nice to have a clean interface. It's not intuitive to do this to get the size.

What do you think?

This is possible, but as I mentioned earlier, the internal sprite would need to be adjusted to ensure it is still drawn correctly.

So, in this method:

bool RenderTexture::initWithWidthAndHeight(int w,
                                           int h,
                                           backend::PixelFormat format,
                                           PixelFormat depthStencilFormat,
                                           bool sharedRenderTarget)
{
    AXASSERT(format == backend::PixelFormat::RGBA8 || format == PixelFormat::RGB8 || format == PixelFormat::RGBA4, "only RGB and RGBA formats are valid for a render texture");

    bool ret = false;
    do
    {
        _fullRect = _rtTextureRect = Rect(0, 0, w, h);
        w                          = (int)(w * AX_CONTENT_SCALE_FACTOR());
        h                          = (int)(h * AX_CONTENT_SCALE_FACTOR());
        _fullviewPort              = Rect(0, 0, w, h);

        setContentSize(Vec2(w, h)); // <<< set content size here
...
}

RenderTexture::getContentSize() will then return the correct size.

For the internal sprite, by default it is anchored at bottom-left (0,0), and the position is 0,0, so the existing behavior will not change. We can also anchor the sprite to middle and draw it in the center of the render texture, if that is preferred:

_sprite->setAnchorPoint(Vec2::ANCHOR_MIDDLE); // <<< ADDED
_sprite->setPosition(_contentSize / 2);  // <<< ADDED

@halx99 Is it reasonable to set the RenderTexture content size and make the above changes to the internal sprite so it is drawn correctly? If so, which is the preferred anchor point of the sprite, 0,0 or middle of render texture?

[rh101]

@halx99 Do we want to address the issue of RenderTexture::getContentSize() always returning 0,0 (it's always been this way since Cocos2d-x)? The only way to get the true size of the render texture is by calling renderTexture->getSprite()->getContentSize(), since the sprite has the correct size set.

It's not a big issue, but it is an easy fix, since we would just need to add setContentSize(Vec2(w, h)); to the RenderTexture::initWithWidthAndHeight() method (as shown in my previous post). RenderTexture::getContentSize() will then return the correct size. This change will not affect the internal sprite or the positioning of the RenderTexture if it is added as a child in the scene. I've checked this in cpp-tests and in my own app, and it does not change the behavior at all.

[halx99]

If no side-affect, we can do it

[asnagni]

Hi @halx99 https://github.com/halx99 , I personally think that we should fix it. It will remove any confusion for the next person. Having a clean a clean working interface it is always the best solution. I know that it is work but it would be the right thing to do. Fixing small things like this one will end up making a big difference for Axmol. That is my opinion. I do really appreciate you considering fixing this and also appreciate the interaction on the Axmol platform .

Thank you, Stay safe

On Aug 30, 2024, at 12:51 AM, halx99 @.***> wrote:

If no side-affect, we can do it

— Reply to this email directly, view it on GitHub https://github.com/axmolengine/axmol/issues/2045#issuecomment-2320041517, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI54DTHRSG6DOUGEY4O46IDZT724ZAVCNFSM6AAAAABLGAYYN6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRQGA2DCNJRG4. You are receiving this because you authored the thread.

[rh101]

@asnagni Can this issue be closed now that the code has been merged?

[rh101]

@halx99 Can this issue be closed? It's already been resolved.

[halx99]

sure