I cannot redo case 1 here on my mac (osx 10.5 ppc).

The userpref window and render window are sharing the same window ID (marked as temp screen). Here they switch nicely, closing prefs and showing render, and vice versa. The chaos in the main window can be due to a graphics card glitch, or something low level in our cocoa code (I use carbon).

Test: check which draw option you have for buffer swaps: User prefs -> system -> draw method. Try all three.

Case 2: I observed this fails completely yes, will work on that.

Wait, the error in case 2 was something else. It's not a bug, the option "image window" sets in the active window the editor to image to display render.

For case 1 I can ask Damien to check if his OSX version has the issue. Jensverwiebe (irc) confirmed draw errors, this is probably because render resizes the drawing window.

Case 1 :

Was using "Automatic" when finding this

Tested with all options,

Triple Buffer/Overlay/Overlay Flip/Full

This is better, not causing the rest of the screen to go crazy..only the temp window. The effect is to now partially fill or overfill the window. ie: the contents do not re-pack themselves to fill the temp window until you grab the window and shake it about.

Note that I use different size user prefs and render windows sizes User prefs is smaller and Window Render is bigger.

The effects just after the two(only 2 I think?) possible orders of opening temp windows are linked. the results are the same for all methods now.

User prefs first then render (new window) ==>http://www.pasteall.org/pic/6916
Render(new win) then user prefs
==>http://www.pasteall.org/pic/6917

If you move the windows to the bottom of the screen it causes a redraw and they then look fine. due to the size differences between the two contents surely they do need to be re-drawn/packed after the swap??

oh BTW the last comment from me was with BF-r33003
I cant reproduce the entire screen craziness now..only the size issue within the temp window. Perhaps something was changed elsewhere between 32991 and now.

It really appears to me as if when going from the smaller Userprefs window to the larger render window the size of the user prefs window is used and visa versa as seen in the images linked in last entry.

Hi Mike,

Really strange, I also noticed things suddenly work better.
There's been a lot of commits all over in the code, and sometimes the dependencies for make (cmake, scons) fail to update well. A successive svn update then can cause a better make. Doing once a while a full 'make clean' is much advised.

So: you mean the issues are resolved now? I love closing reports :)

No ...an issue is still present ..see the links to pasteall images of screen. Its just that now its only the temp window thats in error and needs a refresh/re-pack whatever.

Do you have User Prefs and Render window the same size? IF so you will not see this effect.

I never had this issue, using Carbon PPC version here. Your issue has been confirmed by another mac user with a 10.6 intel system.

Damien: it seems to me that the 'resize window' event from Cocoa to Blender is being sent before the actual window size happens, or the code that reads the actual window size is not giving the right size then.

For completeness svn upped to r33008 and did a clean the re-build.

Still we have an issue *IF* the User Prefs screen is a different size to the Render(new window) screen. (It is for me whatever reason)

I was able to reproduce the issue... a few times, but no more now.
Changing the user prefs window before launching the render in new window.

Ton: Cocoa sends the 'resize window' event when the window is asked to be resized (it is the Cocoa setSize function that itself calls the callback). Thus notification is sent immediately after window has been resized. Value sent is correct.

Is it a kind of race condition (with the background render thread) ? Where for other OSes the notification is sent later, thus in a later iteration of the main loop ?
This may explain why I was able to reproduce it only a few times.

Mike: to rule out any Apple bug fix, can you retry after upgrading to 10.6.5 ?

MBP C2D 2.8GHz nVidia 9400M, OSX 10.6.5

Hi , Damien, Ton,
I upgraded to 10.6.5 and ran tests again. Same issue.

It looks like to me (still trying to learn blender insides) that the "temp" window retains the image size from the last window into which the new content is put.

IF you ever so slightly resize the "temp" window at all Before opening the new one the result is good. This works in either direction. Ren-> User or User-> Ren

FYI system info for current build (10.6.5 and r33029) attached

Mike.

Sadly drivers for ATIs in Mac and Linux always cause troubles... (although my ATI in G5 is fine). Can only be solved if we recruit a volunteer developer with a system similar to this, maybe a bypass then can be coded.

Will put report in the opengl tracker for later review.

Woohoo!

Ton's r33514. fixes a problem I was about to write up.
Ton's r33163. fixes the resize issue seen above Case 1

Case2 still occurs where F12 render appears in "temp" if visible rather than in image window as requeste din UI. Minor compared to the others.

Thanks!

errr spoke too soon....

The strangeness in Case 1 still present if Render-> New Window set :( [[although as mentioned before the entire screen is now not corrupted]]

I'll keep an eye at these issues, but (like your case probably) the reason for corruptions are typically very hard to redo and locate.