Hi,
to reduce the amount of allocations, and therefore speed things up, I
would like to be able to load images into existing surfaces.
So if the supplied surface has the correct attributes for the loaded
image, it should use that surface, rather than load its own.
Would this feature request be accepted? Or would I have to code my own?
cheers,
where is the difference between having img_load creating the surface
or you doing it and loading the image to it?
overall it needs the same amount of computing power
since in both cases you need to load the image onto a surface
which has the image’s properties and which has to be created
either by you or by img_load.
if you really want to speed up things why dont you just
pre-cache all the images during initialization of your
program?On 12/26/2009 01:13 PM, Ren? Dudfield wrote:
Hi,
to reduce the amount of allocations, and therefore speed things up, I
would like to be able to load images into existing surfaces.So if the supplied surface has the correct attributes for the loaded
image, it should use that surface, rather than load its own.
wouldn’t precaching cause an increased memory impact of the application?On Tue, Dec 29, 2009 at 9:57 PM, Marcel Wysocki wrote:
On 12/26/2009 01:13 PM, Ren? Dudfield wrote:
Hi,
to reduce the amount of allocations, and therefore speed things up, I
would like to be able to load images into existing surfaces.So if the supplied surface has the correct attributes for the loaded
image, it should use that surface, rather than load its own.where is the difference between having img_load creating the surface
or you doing it and loading the image to it?
overall it needs the same amount of computing power
since in both cases you need to load the image onto a surface
which has the image’s properties and which has to be created
either by you or by img_load.
if you really want to speed up things why dont you just
pre-cache all the images during initialization of your
program?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Jonathan Swifthttp://www.brainyquote.com/quotes/authors/j/jonathan_swift.html
Hi,
to reduce the amount of allocations, and therefore speed things up, I
would like to be able to load images into existing surfaces.
There may be more allocations going on than you are aware of. OTOH,
maybe not. But, it is common to allocate some working buffers for
decompressing the image. That is often done in the decompression
library so you can’t get rid of it without rewriting the code all the
way down to the libraries that SDL calls.
You might want to measure how fast allocations really are. Turns out
they are much faster than most people expect. If your code is
allocating, then deallocating, and then allocating blocks of the same
size it is most likely that you are getting the same block each time
and that the allocation is taking only a few instructions to execute.
If you have not profiled your code to see how much time you actually
spend doing allocations you are most likely trying to solve a problem
that does not exist.
The real question I have is why do you believe that these allocations
are taking so much time that they are worth worrying about?
So if the supplied surface has the correct attributes for the loaded
image, it should use that surface, rather than load its own.
Like I said, you are worrying about tiny bits of time. Even if you are
streaming video one frame at a time from disk the cost of an
allocation is so small that it just isn’t a problem.
Would this feature request be accepted? ?Or would I have to code my own?
'Can’t say. But, it is more likely to accepted if you send in a patch.
Bob PendletonOn Sat, Dec 26, 2009 at 6:13 AM, Ren? Dudfield wrote:
cheers,
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
If SDL_image did what you want internally, it would be doing the following:
Load the image in whatever format the image is in. This creates a
SDL_Surface.
Convert the image to the format you want. To do this, it would need
to create a second SDL_Surface.
Free the original SDL_Surface.
Return the pointer to the SDL_Surface in the desired format.
You can easily write a routine in a few lines of code that does this for you
and call it in place of IMG_Load().
Doing it that way isn?t using any more allocations than if YOU create a
surface of the right size and bit depth and then could convert the image
into that format. Your suggested way would be:
Create a surface with the desired size and depth. This creates a
SDL_Surface.
Load the image in whatever format the image is in. This creates a
SDL_Surface.
Convert the image to the format you want with the SDL_Surface from
step 1.
Free the SDL_Surface from step 2.
Both ways required 2 surfaces to be created and one to be freed. Neither
way is more efficient than the other, although the 1st way of doing it has
the advantage that you don?t need to know the image width, and height before
you create your surface; doing it the second way would either mean a table
with that info, or opening the file to get that info.
Typically your desired image format is the display format, so you can make
your Helper routine very small. Off the top of my head:
// Load an image and convert it to the currently set video mode.
// This works properly under SDL 1.2.x as long as it is called
// after the call to SDL_SetVideoMode().
// NOTE: It will work properly under SDL 1.3.x, but only when
// using the legacy API. If you use the new 1.3 ?native? API
// then the SDL_DisplayFormat() will return NULL.
SDL_Surface *LoadImageInDisplayFormat( const char *pFile )
{
SDL_Surface *pSurface = NULL;
if ( NULL != pFile )
{
SDL_Surface *pDisplaySurface;
pSurface = IMG_Load( pFile );
if ( NULL != pSurface )
{
pDisplaySurface = SDL_DisplayFormat( pSuface );
if ( NULL != pDisplaySurface )
{
// Free the original surface
SDL_FreeSurface( pSurface );
// Use the converted surface
pSurface = pDisplaySurface;
}
}
}
return pSurface;
}
Behalf Of Vittorio G.From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Sent: Tuesday, December 29, 2009 4:51 PM
To: SDL Development List
Subject: Re: [SDL] sdl_image feature request: loading into an existing
surface?
wouldn’t precaching cause an increased memory impact of the application?
On Tue, Dec 29, 2009 at 9:57 PM, Marcel Wysocki wrote:
On 12/26/2009 01:13 PM, Ren? Dudfield wrote:
Hi,
to reduce the amount of allocations, and therefore speed things up, I
would like to be able to load images into existing surfaces.
So if the supplied surface has the correct attributes for the loaded
image, it should use that surface, rather than load its own.
where is the difference between having img_load creating the surface
or you doing it and loading the image to it?
overall it needs the same amount of computing power
since in both cases you need to load the image onto a surface
which has the image’s properties and which has to be created
either by you or by img_load.
if you really want to speed up things why dont you just
pre-cache all the images during initialization of your
program?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Jonathan Swift
http://www.brainyquote.com/quotes/authors/j/jonathan_swift.html - “May
you live every day of your life.”
Hi,
to reduce the amount of allocations, and therefore speed things up, I
would like to be able to load images into existing surfaces.There may be more allocations going on than you are aware of. OTOH,
maybe not. But, it is common to allocate some working buffers for
decompressing the image. That is often done in the decompression
library so you can’t get rid of it without rewriting the code all the
way down to the libraries that SDL calls.You might want to measure how fast allocations really are. Turns out
they are much faster than most people expect. If your code is
allocating, then deallocating, and then allocating blocks of the same
size it is most likely that you are getting the same block each time
and that the allocation is taking only a few instructions to execute.
hello,
ah good point, thanks.
If you have not profiled your code to see how much time you actually
spend doing allocations you are most likely trying to solve a problem
that does not exist.
The problems are:
?The real question I have is why do you believe that these allocations
are taking so much time that they are worth worrying about?So if the supplied surface has the correct attributes for the loaded
image, it should use that surface, rather than load its own.Like I said, you are worrying about tiny bits of time. Even if you are
streaming video one frame at a time from disk the cost of an
allocation is so small that it just isn’t a problem.Would this feature request be accepted? ?Or would I have to code my own?
'Can’t say. But, it is more likely to accepted if you send in a patch.
Bob Pendleton
Well, I’ll just leave it in pygame if not accepted. So no biggie really.
I think I’ll be able to make a wrapper for the existing functions which just:
Then I can incrementally add more optimized functions as needed. I’ll
probably just start with a jpeg one.
cya,On Tue, Dec 29, 2009 at 11:22 PM, Bob Pendleton wrote:
On Sat, Dec 26, 2009 at 6:13 AM, Ren? Dudfield <@Rene_Dudfield> wrote: