thorvg + SDL_Surface.... possible?

[dtromb]

I'm wondering if it is possible to use thorvg to render directly onto an SDL_Surface (not an SDL_Texture / OpenGL window!)

Can anyone point me in the right direction, if this is an option? Are there examples?

[hermet]

@dtromb Hello, we have no official examples. Have you tried this? https://manpages.debian.org/experimental/libsdl3-image-doc/IMG_Load_RW.3.en.html. I believe the main idea is sharing the ThorVG canvas target buffer with SDL image. I expect it's technically possible.

[dtromb]

Well, SDL_Image is really for loading image formats (.png, .gif, etc), I believe.

What I'm trying is creating an SWCanvas and calling tvg_swcanvas_set_target() through the capi with the address returned in an SDL_Surface.pixels. Since the thorvg Colorspace and the SDL_PixelFormat of the surface are exactly compatible - TVG_COLORSPACE_ARGB8888 and SDL_PIXELFORMAT_ARGB8888, thorvg should be able to just write pixel data into the locked SDL raster.

However, when I call tvg_swcanvas_set_target(), an access violation results. So it looks like my assumption that the "target" is just the (2*width-stride)*height*bytes_per_pixel array of pixels values does not hold. (Here width=stride so the raster is sized width*height*4).

I'm at a loss. Is TVG trying to read/write beyond that logical raster on set_target for some reason? Are there any examples at all of direct use of a SWCanvas target that I could look at? I've started trying to read the source, but I'm still not sure what's going wrong....

[dtromb]

It looks as though the access violation unexpectedly happens at tvgSwCanvas.cpp:88:

auto renderer = static_cast<SwRenderer*>(Canvas::pImpl->renderer);

I also see:

    #ifdef THORVG_SW_RASTER_SUPPORT
    SwCanvas::SwCanvas() : Canvas(SwRenderer::gen()), pImpl(new Impl)
    #else
    SwCanvas::SwCanvas() : Canvas(nullptr), pImpl(new Impl)
    #endif
    {
    }

Do I possibly need a non-default compile-time option here, or these functions have undefined / segfault behavior? Or is this related to something else completely? It looks like tvg_swcanvas_set_target() should be guarded against the #else in the code above with the same #ifdef, though, so I'm not sure.

I call tvg_engine_init(TVG_ENGINE_SW, 4), success. I then call tvg_swcanvas_create(), success. I then call tvg_swcanvas_set_target() as above. Am I missing a step?

[mgrudzinska]

@dtromb
please check this example

I wrote it quickly, so there might be some issues with SDL, but I don't see any memory violations caused by ThorVG.
the result looks as expected:

[dtromb]

TY, this is a very helpful example! This (and my original code!) both work on Linux but fail with segfault on Windows - previously I was only building on Windows. I'll try to more preceisely track it down, I guess.

[dtromb]

Running Dr. Memory shows:

~~Dr.M~~ 
~~Dr.M~~ Error #264: UNADDRESSABLE ACCESS: reading 0xffffffffbd9527d8-0xffffffffbd9527e0 8 byte(s)
~~Dr.M~~ # 0 thorvg-0.dll!tvg::SwCanvas::target          [<path>\src\thorvg\src\renderer\tvgSwCanvas.cpp:90]

(the line number is off because i added a breadcrumb cout << on the line before, which is passed fine and prints to cout)

This is probably some kind of subtle compilation issue - but I'm just running meson setup / compile....

[mgrudzinska]

and are you sure that you have access to write into the buffer (SDL_MUSTLOCK(surface) evaluates to zero)?
and screenSurface->format->BitsPerPixel == 32?

[dtromb]

@mgrudzinska It's not getting far enough to do anything with the buffer or look at that address! (But yes, I lock, and the pixel formats match). It's dying when it tries to access the private implementation Canvas::pImpl pointer of the SWCanvas. The address both the mem debugger and my breadcrumbs tell me is being accessed is for example 0xffffffffbd9527d8, which is indeed not a valid address. The correct address for that run was 0x00000000bd9527d8 (according to breadcumb output just before making that call). In other words, it appears the address of this is mangled by a negation of the high order word when this method is called! I literally have no idea how a thing like this happens. It's almost certainly a VisualStudio compiler bug (unless you can think of a more likely explainer O_o)

Randomly toggling obscure compiler flags in desparation now.... then it's time for a machine code dump =/

[dtromb]

Ok, I still have no idea what the problem is but my workaround is compiling everything 32-bit, and it works just fine on both platforms. Will comment here if I ever find out more, but I strongly doubt this was thorvg-related. Thanks all for your time!

[capnm]

@mgrudzinska I just compiled a static thorvg lib (Debian 12 Linux) and it runs with a simple command line 👌

clang++ -o App -Wall -g  src/SDL_TVG_example.cpp -I../thorvg-git/inc/ \
	-I../thorvg-git/src/bindings/capi/ \
	-L../bin -lthorvg -lpng -lwebp -lSDL2main -lSDL2

./App

[L] RENDERER (../thorvg-git/src/renderer/tvgCanvas.cpp 60): Draw S. -------------------------------- Canvas(0x562396d2d540)
[L] RENDERER (../thorvg-git/src/renderer/tvgCanvas.cpp 62): Draw E. -------------------------------- Canvas(0x562396d2d540)

[dtromb]

Yup! As I mentioned above, I didn't have any problems with it on Linux (or a 32-bit platform on VS on Windows). This seems to just be a weird.

Oh, FWIW I'm using SDL3, the current development version, and the integration still works... (some function names changed). It's great for SDL developers to have this little bit of code available, thx again!

[capnm]

Crazy you can compare both APIs ;)

    tvg::Initializer::init(4, tvg::CanvasEngine::Sw);
    //tvg_engine_init(TVG_ENGINE_SW, 4);