0
\$\begingroup\$

I have one image.png that I load using SDL_IMG. I load by creating a surface. Then I create a texture using CreateTextureFromSurface() and I free the original surface. I repeat the same process but now at the end I use SetColorMod(128, 128, 0) to this new texture. This changes the color of the image as I wanted! Cool!

This whole process is done way before the images are rendered to the screen. The original texture (without the color change) is rendered normally. The texture with the color change creates a mini delay when rendered for the first time. After that it keeps rendering without any delay.

I’m using SDL 2.0.2 (I’m using ubuntu 14.04)

A quick preview of the code to give an idea of what is happening

// load function
func load() {
    newSurface, err = img.Load(fname)
    defer newSurface.Free()
    newTexture, err = renderer.CreateTextureFromSurface(newSurface)
    return newTexture
}

// pre load
func init() {
    sprite1 := load()

    sprite2 := load()
    sprite2.SetColorMod(128, 128, 0)
}

// render...
func render() {
    Renderer.Clear()
    //loop for each object
    obj1 := sprite1
    obj2 := sprite2
    Renderer.CopyEx(obj1, &crop, dst, render.Angle, render.Center, render.Flip)
    // LAG HERE
    Renderer.CopyEx(obj2, &crop, dst, render.Angle, render.Center, render.Flip)
    Renderer.Present()
}
\$\endgroup\$
  • \$\begingroup\$ Are you using hardware accelerated or software rendering? \$\endgroup\$ – Tyyppi_77 May 2 '18 at 15:48
  • \$\begingroup\$ I thought I was having hardware accelerated rendering due to the use of textures, but reading SDL2 doc, it doesn't work on linux... so yeah, it is software rendering. Do you think the caching is not working properly because of that? \$\endgroup\$ – tupan May 2 '18 at 15:57
  • \$\begingroup\$ I don't have access to the code right now (only in 8 hours). I will double check when I get home \$\endgroup\$ – tupan May 2 '18 at 15:59
  • \$\begingroup\$ I've been glancing through SDL's source code and it definitely seems like the first rendering of a texture using a colormod seems pretty slow if the renderer is using a software renderer backend instead of a hardware accelerated one. I can't spot a slowdown in the OpenGL backend though, so this really depends on the renderer backend. \$\endgroup\$ – Tyyppi_77 May 2 '18 at 16:41
  • \$\begingroup\$ Using RendererInfo() I got {opengl {10 3 [372645892 842094169 1448433993 0 0 0 0 0 0 0 0 0 0 0 0 0] 8192 8192}}. It is returning 10 for the rendering flag. That says that it is creating a render that will try hardware accelerate, if it doesnt work it'll use targettexture. Is there another way to check? I went through the doc and couldn't find a better function to return more useful info \$\endgroup\$ – tupan May 3 '18 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.