Logged In: YES
user_id=5402

1 GB RAM on both machines.

Logged In: YES
user_id=103

You have to provide a .blend file example that shows the error. Your statement "moving or scaling the image in the uv window" is also undefined. HOW do you "move" or "scale"? Always give information with excact descriptions of blender menus/tools/buttons.

Logged In: YES
user_id=5402

This happens with All files. Using middle mouse button to move or enlarge an image in the uv window will cause one of mty CPUs to attain 100% usage and halt all functionality within the gui. I don't know how to use the command line so I don't know if the problem can be solved from there or not. I just have to shut the program down. This problem doesn't seem to be quite as prevalent in ZanQdo's Dec. 23 build. Attached is the latest victm.

Logged In: YES
user_id=5402

This happens with All files. Using middle mouse button to move or enlarge an image in the uv window will cause one of mty CPUs to attain 100% usage and halt all functionality within the gui. I don't know how to use the command line so I don't know if the problem can be solved from there or not. I just have to shut the program down. This problem doesn't seem to be quite as prevalent in ZanQdo's Dec. 23 build. Attached is the latest victm.

Logged In: YES
user_id=103

The attached file doesn't have images packed...

Try to make something that crashes with simpler images? Also keep track of the memory you're using. The ATI cards might have very little opengl video ram?

Also: try to make the blender window a tinsy bit smaller than the screen itself. Do NOT use the "fullscreen" button some people still seem to add to blender, that one is a per-definition reason for crashes like this.

Logged In: YES
user_id=2923

Ton this sounds similar to the opengl issue that i encounter with the file browsing i suspect. Ie ATI cards not liking a specific opengl call that is being used. Try turning down/off opengl hardware acceleration and see if that solves it.

Logged In: YES
user_id=103

Moved to opengl tracker to cleanup here. Doesn't mean I don't track this report... I am still curious to know what goes on precisely.

Logged In: YES
user_id=103

Moved to opengl tracker to cleanup here. Doesn't mean I don't track this report... I am still curious to know what goes on precisely.

Logged In: YES
user_id=5402

I didn't pack the file because the multi layer still was 16.8 MB. The problem does not occur with images that are opened in the uv window though, it happens when you are working with the render result image from the temp exr file. Newer CVS versions are much more forgiving, but I have altered my ethic so that I save my file B4 I move or enlarge the image because it still crashes and even happened to me today. As far as opengl is concerned, I recently discovered that ATIOGLXX.DLL is worthless and actually causes system slowdown and Blender crashes, so I have removed it from my System32 folder. Now Blender runs better than ever, much better than when I was having to turn down hardware accelleration in my performance settings. This even improves rendering speed on my machine by 50% as long as raytraced reflections, ray transparency and ambient occlusion aren't used in the render. You can read about other users substituting Nvidia opengl dll in this post and one of the comments from one of the users toward the end of the thread lead to the discovery that the file is totally unnecessary.

http://blenderartists.org/forum/showthread.php?t=56932

Logged In: YES
user_id=5402

I also discovered after the freeze today that when I have to close Blender due to one of these freezes, I can not read from the temp exr file when I reopen the session. I tried several times to bring the image up with hot key R. Any other time this hot key works beautifully. Very nice. I can only assume that Blender is freezing because the image data is somehow being destroyed or corrupted since it is no longer available for viewing.

Logged In: YES
user_id=103

Thanks for the information. Good to hear you found a solution for the slow UI drawing.

It's still confusing to digest from this report whether there's a real bug still. Blender should not freeze ever. Typically bad openGL drivers can cause this. If you then force to quit blender during such a freeze, the temp exr files are only partially written, and will crash Blender. That's a known issue.

Logged In: YES
user_id=5402

The problem occurs on images which are already available as a render result (always occuring with images accessed via the temp exr file), so Blender is never rendering when this happens. A typical scenario would be when I am trying to zoom in on a problem area of an image to try and diagnose a solution. I do not know why or how it occurs, I just know that it sometimes happens when trying to enlarge or move the view of the render result using middle mouse button in the uv window. This NEVER happens when working with the render result from a seperate render window, ONLY when working with the render result from within the uv/image window.

Logged In: YES
user_id=5402

As far I am aware this problem is not at all common as other users at BlenderArtists seem to have no idea what I was refering to when I asked them about the problem B4 bringing it here. I find that a bit strange since it happens to me across multiple computers, but that probably means that it's isolated to the AMD cpu / ATI video card / Logitech optical usb mouse / Windoze XP op-sys combinations on my computers. I have realized this since originally creating this report and am much better able to controll and deal with it. Since it does seem to be so isolated and controllable via good working practices, it probably isn't worth further investigation. Thank you.

This is a generic request to test your bug report and see if it is still an issue in 2.5alpha2 if so please let me know by making a comment in this report ie 'also in 2.5alpha2' and I will add it to the 2.5 bug list.