SDL_image load times

Howdy,

I’m having problems with my SDL OpenGL program. The program loads images
every now and then from a large collection of images. They’re all
800x600 JPEG’s. I’m forced to load the image using SDL_image then move
that onto an OpenGL texture every time.

The problem is it takes too long load each image, so I get a very
distinct lag chunk of about 100ms.

The way I currently load the stuff is along the lines of the following:

tmp = (SDL_Surface *) IMG_Load(file);
surface = SDL_CreateRGBSurface(SDL_SWSURFACE, newW, newH, 32,
0x000000FF, 0x0000FF00, 0x00FF0000, 0xFF000000);
SDL_BlitSurface(tmp, NULL, surface, NULL);
SDL_FreeSurface(tmp);

I’m loading the image to a temporary surface then to another surface
because OpenGL texture’s needs W/H to be a power of 2.

This is about how long it takes to run each call in micro seconds on a
P3-1GHz:
IMG_Load 53171
SDL_CreateRGBSurface 12885
SDL_BlitSurface 23843
SDL_FreeSurface 927

I tried to load all the images in memory… Bad idea, it basically
crashed my Linux box when it finally ran out of memory! I should have
tried working out the maths for it first :slight_smile:

At the moment I’m actually trying to add another thread to solely do
this, but 1) it still chunks, (trying to workout Linux pthread priority
stuff to make it have a lower priority) and 2) thread locking is making
my FPS go unstable :frowning:

Is there a better way?

Thanks

Gerald

I’m forced to load the image using SDL_image then move that onto an OpenGL
texture every time.

Why you need new textures in realtime?

I’m loading the image to a temporary surface then to another surface
because OpenGL texture’s needs W/H to be a power of 2.

And why pictures aren’t correct size?

Is there a better way?

I think there is design problem somewhere.On Wed, Nov 13, 2002 at 04:09:06PM +1100, GAK wrote:

I’m having problems with my SDL OpenGL program. The program loads images
every now and then from a large collection of images. They’re all
800x600 JPEG’s. I’m forced to load the image using SDL_image then move
that onto an OpenGL texture every time.

The problem is it takes too long load each image, so I get a very
distinct lag chunk of about 100ms.

The way I currently load the stuff is along the lines of the following:

tmp = (SDL_Surface *) IMG_Load(file);
surface = SDL_CreateRGBSurface(SDL_SWSURFACE, newW, newH, 32,
0x000000FF, 0x0000FF00, 0x00FF0000, 0xFF000000);
SDL_BlitSurface(tmp, NULL, surface, NULL);
SDL_FreeSurface(tmp);

The problem is not related to IMG_Load, that is just a bit slower than
SDL_LoadBMP.
What you’re doing can result in compatibility problems:
An universally accepted texture, in fact, must be 64,128 or 256 wide or
high; any other resolution will cause problems.
Refer to NeHe’s OpenGL tutorial #7.

There are some workarounds for this:
1)Resize your images using some art program.
2)Use SDL_gfx to resize them realtime
However, this way stretched images will look awful.

3)If you don’t want to lose resolution, split them in many textures (not
recommended)
3)Use mipmaps. They can have any size.
Just keep in mind that, while mipmaps have absolutely the best quality,
they use a BUNCH of RAM.

I attach some code of mine that uses the third option. It’s based on Sam
Lantinga’s version of NeHe’s tutorials

P3-1GHz:

IMG_Load 53171
SDL_CreateRGBSurface 12885
SDL_BlitSurface 23843
SDL_FreeSurface 927

I tried to load all the images in memory… Bad idea, it basically
crashed my Linux box when it finally ran out of memory! I should have
tried working out the maths for it first :slight_smile:

Obviously. If you use plain textures, every image takes 800x600x4=1.8MB of RAM.
If you use 400x300 textures you will need 450kB of RAM for each texture,
without a considerable resolution loss.

Guido Imperiale

@CRUSADER_KY-------------------------------
CRV?ADER/KY
KnowledgE is PoweR
-------------- next part --------------
/*
myGL - an essential SDL framework for OpenGL - myGL.h
Copyright © 2002 Guido Imperiale

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Guido Imperiale
@CRUSADER_KY

*/

#include <stdlib.h>
#include <stdio.h>

#include <SDL/SDL.h>
#include <SDL/SDL_image.h>

#if defined(APPLE) && defined(MACH)
#include <OpenGL/glaux.h>
//#include <OpenGL/glut.h>
#else
#include <GL/glaux.h>
//#include <GL/glut.h>
#endif

#define NO_FLAGS 0
#define MYGL_TEXTURE 0
#define MYGL_MIPMAP 1

typedef enum __myGL_RGBOrder {UNRECOGNIZED,RGB,BGR,GRB,GBR,RBG,BRG} myGL_RGBOrder;

SDL_Surface * myGL_Init(int width,
int height,
int depth,
Uint32 init_flags,
Uint32 video_flags,
char * caption);

SDL_Surface * myGL_LoadImage(char * filename);

void myGL_LoadTexture(char * filename,
GLuint texture,
GLfloat MinFilter,
GLfloat MagFilter,
BOOL use_mipmap);

void myGL_CreateTextureFrom(SDL_Surface * image,
GLuint texture,
GLfloat MinFilter,
GLfloat MagFilter,
BOOL use_mipmap);

-------------- next part --------------
/*

  • myGL - an essential SDL framework for OpenGL - myGL.c
  • Copyright © 2002 Guido Imperiale
  • This code is released under the terms of the GNU LGPL.
  • Please refer to myGL.h for more informations.
    */

#include “myGL.h”

SDL_Surface * myGL_Init(int width,
int height,
int depth,
Uint32 init_flags,
Uint32 video_flags,
char * caption)
{
SDL_Surface * screen = NULL;

/* Initialize SDL for video output */
if ( SDL_Init(SDL_INIT_VIDEO | init_flags) < 0 ) {
    fprintf(stderr, "Unable to initialize SDL: %s\n", SDL_GetError());
    exit(1);
}

atexit(SDL_Quit);

/* Create an OpenGL screen */
if ( (screen = SDL_SetVideoMode(width, height, depth, SDL_OPENGL | video_flags)) == NULL ) {
    fprintf(stderr, "Unable to create OpenGL screen: %s\n", SDL_GetError());
    exit(2);
}


/* Set the title bar in environments that support it */
SDL_WM_SetCaption(caption, caption);


/* Projection matrix setup */
glMatrixMode(GL_PROJECTION);            //Select The Projection Matrix
glLoadIdentity();                       //Reset The Projection Matrix
                                        //Calculate The Aspect Ratio Of The Window
gluPerspective(45.0f,(GLfloat)width/(GLfloat)height,0.1f,100.0f);

/*other setup*/
glMatrixMode(GL_MODELVIEW);             //Select The Modelview Matrix
glEnable(GL_TEXTURE_2D);				//Enable Texture Mapping 
glShadeModel(GL_SMOOTH);                //Enable Smooth Color Shading
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);   //This Will Clear The Background Color To Black
glBlendFunc(GL_SRC_ALPHA,GL_ONE);		//Blending Function Based On Source Alpha Value

/*Depth Buffer setup*/
glClearDepth(1.0);                      //Enables Clearing Of The Depth Buffer
glDepthFunc(GL_LESS);                   //The Type Of Depth Test To Do FIXME:GL_LEQUAL?
glEnable(GL_DEPTH_TEST);                //Enables Depth Testing

/*Quality settings*/
glHint(GL_FOG_HINT,                    GL_NICEST);			
glHint(GL_LINE_SMOOTH_HINT,            GL_NICEST);			
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);			
glHint(GL_POINT_SMOOTH_HINT,           GL_NICEST);			
glHint(GL_POLYGON_SMOOTH_HINT,         GL_NICEST);			

return screen;

}

SDL_Surface * myGL_LoadImage(char * filename)
{
Uint8 *rowhi, *rowlo, *tmpbuf;
Uint8 tmpch;
SDL_Surface * image;
myGL_RGBOrder order = UNRECOGNIZED;
int i, j;

if ((image = IMG_Load(filename)) == NULL) {
    fprintf(stderr, "Unable to load %s: %s\n", filename, SDL_GetError());
    return(NULL);
}

if (image->format->BitsPerPixel != 24 || image->format->BytesPerPixel != 3) {
    fprintf(stderr,"Image is %d bpp and %d Bpp",image->format->BitsPerPixel,image->format->BytesPerPixel);
    return(NULL);
}

//Determine RGB components order
if (image->format->Rshift == 16 && image->format->Gshift == 8)
        order = BGR;                        //BMP
else if (image->format->Bshift == 16 && image->format->Gshift == 8)
        order = RGB;                        //textures, JPEG

//GL textures are upside down and RGB
if ((tmpbuf = malloc(image->pitch)) == NULL ) {
    fprintf(stderr, "Out of memory\n");
    return(NULL);
}

rowhi = (Uint8 *)image->pixels;
rowlo = rowhi + (image->h-1) * image->pitch;   //last line of the image

for (i=0; i<image->h/2; ++i)
{
    //Switch the single pixels of a line on themselves from BGR to RGB
    switch (order)
    {
        case RGB:                               //nothing to do
            break;
        case BGR:                               //swap B and R
            for ( j=0; j<image->w; ++j ) {
                tmpch = rowhi[j*3];
                rowhi[j*3] = rowhi[j*3+2];
                rowhi[j*3+2] = tmpch;
                tmpch = rowlo[j*3];
                rowlo[j*3] = rowlo[j*3+2];
                rowlo[j*3+2] = tmpch;
            }
            break;
        //I'm too lazy to write support :). Thus, all the image formats supported by SDL_image
        //are either RGB or BGR. FIXME: I experienced a green line using a 700x469 BMP photograph,
        //while the corresponding JPG works well.
        default:                                
            fputs("Unrecognized image format",stderr);
            SDL_FreeSurface(image);
            return NULL;
            break;
    }
    
    //switch the line on top and the one on the bottom
    memcpy(tmpbuf, rowhi, image->pitch);
    memcpy(rowhi, rowlo, image->pitch);
    memcpy(rowlo, tmpbuf, image->pitch);
    rowhi += image->pitch;
    rowlo -= image->pitch;
}
free(tmpbuf);
return(image);

}

// Load Bitmap And Convert To Texture
void myGL_LoadTexture(char * filename, GLuint texture, GLfloat MinFilter, GLfloat MagFilter, BOOL use_mipmap)
{
//Load Texture
SDL_Surface * image;

image = myGL_LoadImage(filename);
if (image==NULL) {
    exit(1);
    fprintf(stderr,"Error loading image: %s\n",filename);
}

//Create Texture	
myGL_CreateTextureFrom(image,texture,MagFilter,MinFilter,use_mipmap);

SDL_FreeSurface(image);

};

// Create a texture from pixel data
void myGL_CreateTextureFrom(SDL_Surface * image, GLuint texture, GLfloat MinFilter, GLfloat MagFilter, BOOL use_mipmap)
{
glBindTexture(GL_TEXTURE_2D, texture); // 2d texture (x and y size)

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,MagFilter);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,MinFilter);

if (!use_mipmap)
    if (image->w != 64 || image->w != 128 || image->w != 256 ||
        image->h != 64 || image->h != 128 || image->h != 256)
        use_mipmap = TRUE;              //force mipmap for non-standard textures

if (use_mipmap)
    gluBuild2DMipmaps(GL_TEXTURE_2D, 3, image->w, image->h, GL_RGB, GL_UNSIGNED_BYTE, image->pixels);
else
    glTexImage2D(GL_TEXTURE_2D,         //type of texture
                 0,                     //level of detail (used by mipmaps)
                 3,                     //components per pixel
                 image->w, image->h,    //image width and height
                 0,                     //image border
                 GL_RGB,                //colors order
                 GL_UNSIGNED_BYTE,      //components data type
                 image->pixels);        //pixel data

}

I’m forced to load the image using SDL_image then move that onto an
OpenGL
texture every time.

Why you need new textures in realtime?

Think of it as a slide-show of images.

I’m loading the image to a temporary surface then to another surface
because OpenGL texture’s needs W/H to be a power of 2.

And why pictures aren’t correct size?

An image that is 1024x1024 takes longer to load then the process of
loading the original 800x600 sized image and converting it to 1024x1024.

Gerald> On Wed, Nov 13, 2002 at 04:09:06PM +1100, GAK wrote:

The problem is not related to IMG_Load, that is just a bit slower than
SDL_LoadBMP.
What you’re doing can result in compatibility problems:
An universally accepted texture, in fact, must be 64,128 or 256 wide
or
high; any other resolution will cause problems.
Refer to NeHe’s OpenGL tutorial #7.

There are some workarounds for this:
1)Resize your images using some art program.

My reply to Jacek’s post I’ve mentioned that it takes longer to load the
1024x1024 image and not convert then it is to convert it from 800x600 to
1024x1024. A call to glGetIntegerv(GL_MAX_TEXTURE_SIZE, &maxTextureSize)
gives me 2048. Why is anything higher then 256 a problem if OpenGL tells
me 2048 is the max? OpenGL seems to handle a texture of 1024x1024 just
fine. I’m more concerned about is the file load + jpeg decoding times.

2)Use SDL_gfx to resize them realtime
However, this way stretched images will look awful.

I’d prefer to keep them at their original quality. :confused:

3)If you don’t want to lose resolution, split them in many textures
(not
recommended)

I just tried splitting the image up into segments of 512 and smaller
(with a power of 2) when needed. It ended up being 9 parts to it. The
512x512 chunk alone took just under 50ms. This took as long as one
800x600 image in total.

I also tried with 6 parts and set a maximum size of 256 chunks. Both
methods took as long. The best result out of all of that is 6 parts, but
not much improvement over my current setup.

3)Use mipmaps. They can have any size.
Just keep in mind that, while mipmaps have absolutely the best
quality,
they use a BUNCH of RAM.
I attach some code of mine that uses the third option. It’s based on
Sam
Lantinga’s version of NeHe’s tutorials

I’ll give this a go, but doesn’t it still require me to use SDL_image to
load the image in the first place?

Thanks

Gerald

if you’re doing a slideshow, why not load the images while another image is
being displayed? is it possible to know which images could come next? if
there’s only a couple/few, you could preload them

also, you could load a low-res version of the image and display that until
you have loaded the higher-res one.

it is going to take some amount of time to load the image, no matter how
you do it. 50milliseconds isn’t bad for loading over 1.5 million bytes of
data and decoding it…

also, you could use an un-encoded type of image, like bmp to cut down on
load times, but it would take more hdd space.

M@ the MadProgrammer_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

if you’re doing a slideshow, why not load the images while another
image
is
being displayed? is it possible to know which images could come next?
if
there’s only a couple/few, you could preload them
also, you could load a low-res version of the image and display that
until
you have loaded the higher-res one.

I’m displaying other stuff on the screen that is high fps dependant.

it is going to take some amount of time to load the image, no matter
how
you do it. 50milliseconds isn’t bad for loading over 1.5 million bytes
of
data and decoding it…

True :slight_smile:

also, you could use an un-encoded type of image, like bmp to cut down
on
load times, but it would take more hdd space.

Didn’t really think about that one :slight_smile: I will try that!

Thanks

Gerald

My reply to Jacek’s post I’ve mentioned that it takes longer to load
the 1024x1024 image and not convert then it is to convert it from
800x600 to 1024x1024. A call to glGetIntegerv(GL_MAX_TEXTURE_SIZE,
&maxTextureSize) gives me 2048. Why is anything higher then 256 a
problem if OpenGL tells me 2048 is the max? OpenGL seems to handle a
texture of 1024x1024 just fine. I’m more concerned about is the file
load + jpeg decoding times.

What kind of images are those?
Animation?

If the difference between images is quite small you beter make deltas
and save those instead of individual images. -> Faster loading times.

So do raw deltas and use RLE to pack the deltas. Then simply load those
and unrle the needed parts to the upload surface (which dimensions are
power of 2) so no need to make many surfaces. -> simply uplad it to OGL

You can even make it more intelligent and use two buffers and make the
deltas two frames back instead of one. So while the one is uploaded
using DMA you can load and encode the next frame.

The resolution you use could still be THE problem.

So use gimp or similar program to scale the pictures in 512*512
resolution. It will lose it’s aspect, but the opengl code will make the
correction for you. This is, because you stretch the square texture to
the original quad you are drawing. So after all it will have the same
aspect than the original picture).

PS. If it’s animation then you can quite safely drop the resolution
down, because from animation you can’t see the details so easily.

The problem is not related to IMG_Load, that is just a bit slower than
SDL_LoadBMP.
What you’re doing can result in compatibility problems:
An universally accepted texture, in fact, must be 64,128 or 256 wide
or
high; any other resolution will cause problems.
Refer to NeHe’s OpenGL tutorial #7.

There are some workarounds for this:
1)Resize your images using some art program.

My reply to Jacek’s post I’ve mentioned that it takes longer to load the
1024x1024 image and not convert then it is to convert it from 800x600 to
1024x1024.
I suggested you to resize them to 400x300.

A call to glGetIntegerv(GL_MAX_TEXTURE_SIZE, &maxTextureSize)
gives me 2048. Why is anything higher then 256 a problem if OpenGL tells
me 2048 is the max? OpenGL seems to handle a texture of 1024x1024 just
fine. I’m more concerned about is the file load + jpeg decoding times.

In NeHe’s OpenGL tutorial is just said “compatibility reasons”. That means
that probably your program won’t work on older video cards.
Email NeHe if you want more info.

2)Use SDL_gfx to resize them realtime
However, this way stretched images will look awful.

I’d prefer to keep them at their original quality. :confused:

3)If you don’t want to lose resolution, split them in many textures
(not
recommended)

I just tried splitting the image up into segments of 512 and smaller
(with a power of 2) when needed. It ended up being 9 parts to it. The
512x512 chunk alone took just under 50ms. This took as long as one
800x600 image in total.

I also tried with 6 parts and set a maximum size of 256 chunks. Both
methods took as long. The best result out of all of that is 6 parts, but
not much improvement over my current setup.

3)Use mipmaps. They can have any size.
Just keep in mind that, while mipmaps have absolutely the best
quality,
they use a BUNCH of RAM.
I attach some code of mine that uses the third option. It’s based on
Sam
Lantinga’s version of NeHe’s tutorials

I’ll give this a go, but doesn’t it still require me to use SDL_image to
load the image in the first place?
Of course, but
1)You don’t have to mess up with the image. Just load it, correct it (take
a look at the code I’ve sent you) and send it to the opengl function.
2)SDL_image isn’t a problem, as it’s practically as fast as SDL_LoadBMP
(and even faster is your hard disk is slow).
However, loading textures of that dimension requires A LOT of time,
whatever you do.>Thanks

Gerald


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

also, you could use an un-encoded type of image, like bmp to cut down
on
load times, but it would take more hdd space.

If you’ve got a slow hard disk, the program will actually slow down. And
you will waste space, too :)_______________________________________________

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Is it slide show or animation? If it’s animation - why use pictures and not
movie format?On Thu, Nov 14, 2002 at 12:51:01PM +1100, GAK wrote:

I’m displaying other stuff on the screen that is high fps dependant.

also, you could use an un-encoded type of image, like bmp to cut
down

on

load times, but it would take more hdd space.

If you’ve got a slow hard disk, the program will actually slow down.
And
you will waste space, too :slight_smile:

The JPEG sizes are ~100KB and the BMP became ~800KB. It did actually
slow down quite a bit. So yes, it does seem like it is the hard drive
access times being the slow part of loading it.

My reply to Jacek’s post I’ve mentioned that it takes longer to load
the 1024x1024 image and not convert then it is to convert it from
800x600 to 1024x1024.
I suggested you to resize them to 400x300.

It just doesn’t look quite as clear/crisp. I know I’m asking for too
much :slight_smile:

If I was to use images at that resolution I might as well bump down my
screen resolution, which I’m considering.

Gerald

What kind of images are those?
Animation?

The images are quite different each time.

The resolution you use could still be THE problem.

So use gimp or similar program to scale the pictures in 512*512
resolution. It will lose it’s aspect, but the opengl code will make
the
correction for you. This is, because you stretch the square texture to
the original quad you are drawing. So after all it will have the same
aspect than the original picture).

512x512 might just be close enough to make it look OK, but it still does
take 50ms on my 4200rpm drive :slight_smile:

A solution I’ve thought about was to use a thread to just load those
images. I’ve mentioned this before saying that it still chunks the whole
process when SDL_image runs. Linux threads seem to be an iffy thing when
it comes to how much priority each thread gets. The subject is off-topic
so I guess I’ll leave it at that. However for the thread that loads the
image, I’ll try putting a (micro)sleep in the SDL_image code for the bit
that loads the data from the HDD to memory so that the gfx thread gets
time-slices during the transfer.

Gerald

But what are you doing that 50ms for a texture load matters? Are you
trying to continue animating something else while a new picture loads?
(Not likely on PC hardware, at least not smoothly.) Are you trying to
stream animation at 30fps from 30*seconds jpegs? (threads wouldn’t
help; the CPU has to be spent somewhere, jpegs just aren’t made for
that.) You’re saying “decompressing large image files takes time”;
well, yeah, it does. Don’t make us guess what you really want. :)On Fri, Nov 15, 2002 at 10:15:59AM +1100, GAK wrote:

What kind of images are those?
Animation?

The images are quite different each time.


Glenn Maynard

But what are you doing that 50ms for a texture load matters? Are
you
trying to continue animating something else while a new picture loads?
(Not likely on PC hardware, at least not smoothly.) Are you trying to
stream animation at 30fps from 30*seconds jpegs? (threads wouldn’t
help; the CPU has to be spent somewhere, jpegs just aren’t made for
that.) You’re saying “decompressing large image files takes time”;
well, yeah, it does. Don’t make us guess what you really want. :slight_smile:

Ok I’ll explain it :slight_smile:

It’s a sort of presentation application.

Every 10 seconds one new image is shown on the screen while there’s some
text (SDL_ttf) on the bottom ~50 pixels on the screen that is meant to
be scrolling smoothly. There are bits that don’t use SDL where it plays
an MPEG file instead of the image on the top, but the scrolling text
keeps going constantly.

That’s basically it.

For the scrolling text, I’m setting the position based on a timer. Eg:

textX = (CurrentTime - StartingTime) * ConstantSpeed

It’s the only way I could think of to make it smooth with a fractional
value to X, rather then adding a set value to X for each frame since
each frame time isn’t exact. Eg:

textX += ConstantSpeed;

With a cool FPS of 100, this is very smooth looking until I try and load
an image!

Gerald

Maybe you just want to do the load in another thread , so it doesn’t
block…

???On Thu, 2002-11-14 at 17:06, GAK wrote:

Ok I’ll explain it :slight_smile:

It’s a sort of presentation application.

Every 10 seconds one new image is shown on the screen while there’s some
text (SDL_ttf) on the bottom ~50 pixels on the screen that is meant to
be scrolling smoothly. There are bits that don’t use SDL where it plays
an MPEG file instead of the image on the top, but the scrolling text
keeps going constantly.

That’s basically it.

For the scrolling text, I’m setting the position based on a timer. Eg:

textX = (CurrentTime - StartingTime) * ConstantSpeed

It’s the only way I could think of to make it smooth with a fractional
value to X, rather then adding a set value to X for each frame since
each frame time isn’t exact. Eg:

textX += ConstantSpeed;

With a cool FPS of 100, this is very smooth looking until I try and load
an image!

Gerald


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Maybe you just want to do the load in another thread , so it doesn’t
block…

Yeah, the plan is to put sleeps in SDL_image which would give the
graphics thread time-slices to keep going. Is that what you mean?

Gerald

Keep in mind that when SDL_image is waiting for disk I/O, the kernel
should put the thread to sleep anyway…

also you could go the other way, and yeild timeslices when you have a
overly high framerate… (If you decide 50 FPS is acceptable, then you
can issue a delay when you’re running above that… )

-LorenOn Thu, 2002-11-14 at 17:23, GAK wrote:

Maybe you just want to do the load in another thread , so it doesn’t
block…

Yeah, the plan is to put sleeps in SDL_image which would give the
graphics thread time-slices to keep going. Is that what you mean?

Give it a try; I’d be interested in knowing the results. I’d expect it
wouldn’t be completely smooth; if you’re spending a bunch of CPU loading,
you’re not spending it rendering, so you’ll miss a few frames. But I
suppose that might be acceptable for your app. (A lot of console games
play loading tricks, and are still smooth, but it’s a lot harder on
the random hardware of PCs.)On Fri, Nov 15, 2002 at 12:23:39PM +1100, GAK wrote:

Maybe you just want to do the load in another thread , so it doesn’t
block…

Yeah, the plan is to put sleeps in SDL_image which would give the
graphics thread time-slices to keep going. Is that what you mean?


Glenn Maynard

Yeah, the plan is to put sleeps in SDL_image which would give the
graphics thread time-slices to keep going. Is that what you mean?

You don’t need sleeps for that. Just load ahead some images in another
thread so that the image needed is there in time. You image loading
thread will be sent to sleep anyway when waiting for your hard disc.

Ciao,
Eike
-------------- next part --------------
A non-text attachment was scrubbed…
Name: winmail.dat
Type: application/ms-tnef
Size: 2504 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20021115/749141ce/attachment.bin