I’ve basically finished porting my application to SDL 1.3. Behaves
much like with SDL 1.2, except that I sometimes get garbage where a
transparent area should be. Since it is not really consistent, I
considered some sort of memory corruption and ran valgrind to have a
look.
It turns out, if I run valgrind ----malloc-fill=0x80, the transparent
areas in question are consistently gray,
I had one place in my code where I malloc’d some pixels, but those get
initialised with whatever is loaded from a PNG file. The next
candidate was the pixel data of my streaming SDL_Textures. And indeed,
once I made the patch below, everything worked fine.
It’s late now, so I haven’t actually figured out why those pixels do
not get properly initialised in my code. I’m pretty sure I’m locking
the texture before writing to the pixels, so they should get set to
some defined values, right? Or is that the responsibility of the
application?
Right now it’s the responsibility of the application to completely fill all
the textures it uses. If lots of people would prefer that textures are
initialized to zero, we can do that, it would just slow down texture
creation slightly.On Thu, Feb 17, 2011 at 3:29 PM, Kai Sterker <kai.sterker at gmail.com> wrote:
I’ve basically finished porting my application to SDL 1.3. Behaves
much like with SDL 1.2, except that I sometimes get garbage where a
transparent area should be. Since it is not really consistent, I
considered some sort of memory corruption and ran valgrind to have a
look.
It turns out, if I run valgrind ----malloc-fill=0x80, the transparent
areas in question are consistently gray,
I had one place in my code where I malloc’d some pixels, but those get
initialised with whatever is loaded from a PNG file. The next
candidate was the pixel data of my streaming SDL_Textures. And indeed,
once I made the patch below, everything worked fine.
It’s late now, so I haven’t actually figured out why those pixels do
not get properly initialised in my code. I’m pretty sure I’m locking
the texture before writing to the pixels, so they should get set to
some defined values, right? Or is that the responsibility of the
application?
I doubt it would slow things down enough that anyone would notice. A FillMem
operation is very, very fast. I tested it a while back, and it took me about 1
second to zero out 2 GB of memory. Granted, I’m running on some monster
hardware, but on the other hand your average texture is measured in kilobytes.________________________________
From: slouken@libsdl.org (slouken)
Subject: Re: [SDL] Streaming textures not properly initialized?
Right now it’s the responsibility of the application to completely fill all the
textures it uses. If lots of people would prefer that textures are initialized
to zero, we can do that, it would just slow down texture creation slightly.
Thanks!On Thu, Feb 17, 2011 at 3:29 PM, Kai Sterker <kai.sterker at gmail.com> wrote:
I’ve basically finished porting my application to SDL 1.3. Behaves
much like with SDL 1.2, except that I sometimes get garbage where a
transparent area should be. Since it is not really consistent, I
considered some sort of memory corruption and ran valgrind to have a
look.
It turns out, if I run valgrind ----malloc-fill=0x80, the transparent
areas in question are consistently gray,
I had one place in my code where I malloc’d some pixels, but those get
initialised with whatever is loaded from a PNG file. The next
candidate was the pixel data of my streaming SDL_Textures. And indeed,
once I made the patch below, everything worked fine.
It’s late now, so I haven’t actually figured out why those pixels do
not get properly initialised in my code. I’m pretty sure I’m locking
the texture before writing to the pixels, so they should get set to
some defined values, right? Or is that the responsibility of the
application?
I doubt it would slow things down enough that anyone would notice. A
FillMem operation is very, very fast. I tested it a while back, and it took
me about 1 second to zero out 2 GB of memory. Granted, I’m running on some
monster hardware, but on the other hand your average texture is measured in
kilobytes.
As long as the address isn’t memory mapped to GPU memory where each write
becomes a bus operation, yes.On Thu, Feb 17, 2011 at 7:27 PM, Mason Wheeler wrote:
I doubt it would slow things down enough that anyone would notice. A FillMem operation is very, very fast. I tested it a while back, and it took me about 1 second to zero out 2 GB of memory. Granted, I’m running on some monster hardware, but on the other hand your average texture is measured in kilobytes.
If you zero initialise something first and then write something else into it you have
clearly DOUBLED the cost of writing.
If you want to do this in a “safe” way, either provide two constructor functions,
or one with a flag (defaulting to auto-zero).On 18/02/2011, at 12:27 PM, Mason Wheeler wrote:
I doubt it would slow things down enough that anyone would notice. A
FillMem operation is very, very fast. I tested it a while back, and it took
me
about 1 second to zero out 2 GB of memory. Granted, I’m running on some
monster hardware, but on the other hand your average texture is measured
in kilobytes.
If you zero initialise something first and then write something else into it you
have
clearly DOUBLED the cost of writing.
Only if the cost of a memory copy operation is the same as the cost of a
memory fill operation. But it’s not.
Mason>----- Original Message ----
From: john skaller
Subject: Re: [SDL] Streaming textures not properly initialized?
On 18/02/2011, at 12:27 PM, Mason Wheeler wrote: