On Mon, Sep 24, 2012 at 12:35 PM, Tobias Leich <em...@froggs.de> wrote:
> Am 24.09.2012 18:07, schrieb Chris Marshall:
>> On Mon, Sep 24, 2012 at 10:41 AM, Tobias Leich <em...@froggs.de> wrote:
>>> Hi Chris,
>>> The performance is poor of course.
>>> I tried to use the piddle's pointer (->dataref or so) but it looks like
>>> it is not pointing to a usable memory area.
>> $piddle->get_dataref returns a scalar reference to a perl
>> PV whose string content _is_ the data block.  You should
>> be able to get the starting location for the pixel data (i.e.,
>> the string) via SvPV.

> Okay, so we need to change the Surface's XS code to accept that.
>>> It looks like there are more than 4 bytes per pixel, and libSDL can't
>>> handle that.
>> Per the above, the get_dataref returns an RV to an Sv with
>> the data in the string.  It is just a contiguous block of memory.
>> As far as I know, all the SDL memory buffers are just
>> contiguous blocks of memory (ignoring variations due to
>> stride, alignment,...)

> The memory block is not the point. It matters how the pixels are stored
> in that block.

> LibSDL can use 1 to 4 bytes per Pixel. And we can tell it how a pixel
> looks like. If it is RGB or RGBA or ABGR or whatever.
> But it is important to know how the pixels are stored, since otherwise
> it might use the alpha channel for the red color.

PDL supports arbitrary numbers of dimensions of
data.  All that we need to know is how SDL is treating
the data so that an equivalent mapping is set up for
processing on the PDL side.

>> Speaking of documentation, do you have any on the
>> actual perl<->libSDL bindings an data structures?  Trying
>> to read XS is not the simplest way to sort things out---
>> especially since I am far for an expert on some of the
>> tricky XS technologies.

Thanks for the refs.  --Chris

> Of course. for example:
> http://sdl.perl.org/documentation.html
> http://search.cpan.org/~jtpalmer/SDL-2.540/
> https://github.com/PerlGameDev/SDL/tree/master/lib/pods
>> --Chris
>>> Cheers, Tobias
>>> Am 24.09.2012 16:09, schrieb Chris Marshall:
>>>> I took a look at the gist and it looks reasonable
>>>> (I can't run it because I don't have the SDL module
>>>> and lib installed on my system), however...
>>>> I would expect the performance to be *very* poor
>>>> since the image data is essentially being converted
>>>> from packed byte data to a perl list and then poked
>>>> a byte at a time into the SDL surface data.
>>>> The better approach would be to wrap a PDL object
>>>> (a.k.a. piddle) into an SDL surface.  Then you could
>>>> just lock, copy the data via a PDL direct assignment,
>>>> unlock and use SDL.  There is an examples/pdl.pl
>>>> that shows how to do the wrapping.
>>>> BUT, I took a look at the xs code and it appears
>>>> that your SDL_Surface objects no longer use a
>>>> packed-string representation for the SDL surface
>>>> data.  If that is the case, I would be surprised if
>>>> the pdl.pl example works at all now.
>>>> If someone could verify this, I would appreciate it.
>>>> If that is the case, it should be straightforward to
>>>> modify the SDL_CreateRGBSurfaceFrom routine
>>>> to allow for a SvPV for pixel data as one alternative.
>>>> Given the power of PDL for whole-image data
>>>> manipulation, allowing for easy interoperability
>>>> with the current SDL module would benefit both
>>>> our user and developer communities.
>>>> Regards,
>>>> Chris
>>>> On Sun, Sep 23, 2012 at 3:07 PM, Tobias Leich <em...@froggs.de> wrote:
>>>>> Hi, Andrei asked some days ago how to load an image via PDL and but it
>>>>> in a Surface to use it in SDL.
>>>>> The example is here: https://gist.github.com/3772701
>>>>> I'll put that in the examples folder too.
>>>>> Cheers, Tobias

Reply via email to