Freeze canvas

Hi group,
I have a problem and maybe somebody had got the same anytime.

My program uses an Animator thread to invoke the display method. The ‘display’ method of the GLCanvas invoques secuentially a method called ‘render’ on every object to be rendered (sphere, cube, etc.)
This works fine.

Also I have another thread called Updater, that every 500ms invokes the method ‘Update’ secuentially on every object. Thus when an object needs to be updated (change its color or load an image) the method ‘update’ is responsible for this.

My problem comes when I have, for example, 20 object that needs to load an image from disk (aprox. 30kb). It seems that the ‘update’ task executed in the ‘Updater’ thread consumes to much resources and the Animator thread or ‘Render’ methods are paused until the images are loaded.
In summary, the canvas seems freeze for a while.

I create the Updater thread as ‘daemon’ and with MIN_PRIORITY.

Anybody has found the same problem in any application?
Any ideas to solve it?

Thanks in advice.

PD: I have 64mb memory ATI card.

The TextureLoader bundled with JOGL has afaik functionality for background loading.

Similair problems have been posted in this forum. It seems even little harddisk I/O completely blocks the gfx-drivers.

I haven’t been able to test this yet, but you might want to narrow it down in this direction, for example, simply read a ‘random’ file very slowly (read-loop with sleeps) during your rendering and see what happens.

Thanks to both.

Cylab, I have used Texture class and the same problem ocurrs. Now I’m using ImageIO to read image and gl.glTexImage2s by hand to set the texture. There is no diference.

Riven, thanks for the coment, I try to put a sleep in the read proces and see what happens, but I don’t know what solution I can get.
Also, I saw the source code of a program that runs in the same way as mine (with a Renderred and an Updater thread to load data) and all its fine with it, the images are loaded secuentially but without freeze the canvas :frowning:

i didn’t say you should put a sleep in the texture-loader, but read a random file in a seperate thread with low priority, and see whether that influences the driver-performance. It’s just about determining whether this is the cause, not to fix the problem.