BF-blender Os X 10.3 -- 2.34 Rel. cand. 3 - 04/08/02 UPDATE
Moderators: jesterKing, stiv
BF-blender Os X 10.3 -- 2.34 Rel. cand. 3 - 04/08/02 UPDATE
We are now officially in B-con 4 situation
a new Os X build with last CVS is available there
Mac Os X RC3
Many thanks to Sirdude which hosted the RC2 (and to Gabio wich hosted the previous one)
Please test carefully, this is from what we will build the release version
a new Os X build with last CVS is available there
Mac Os X RC3
Many thanks to Sirdude which hosted the RC2 (and to Gabio wich hosted the previous one)
Please test carefully, this is from what we will build the release version
Last edited by lukep on Mon Aug 02, 2004 1:07 am, edited 1 time in total.
I'm experiencing some serious interface responsiveness issues. 4/5 times it takes over 2 seconds for a reaction to input. This includes the 3D windows, buttons, menus... pretty much all of it. Once rotating the 3D view took 8 seconds to respond.
For example, with a light selected I click on the material settings button... and 4 seconds later Blender responds. I click on world settings, another 3 seconds.
iMac G4 1.25GHz running 10.3.4, 512MB RAM, no other software running
For example, with a light selected I click on the material settings button... and 4 seconds later Blender responds. I click on world settings, another 3 seconds.
iMac G4 1.25GHz running 10.3.4, 512MB RAM, no other software running
-
- Posts: 0
- Joined: Sat Jul 31, 2004 2:50 am
-
- Posts: 0
- Joined: Mon Apr 05, 2004 6:44 pm
Render Bug related to Emit attribute on Surfaces
The render bug that Kerosene noted in the previous build still remains in the OS X version.
That's a serious problem.akator wrote:I'm experiencing some serious interface responsiveness issues. 4/5 times it takes over 2 seconds for a reaction to input. This includes the 3D windows, buttons, menus... pretty much all of it. Once rotating the 3D view took 8 seconds to respond.
For example, with a light selected I click on the material settings button... and 4 seconds later Blender responds. I click on world settings, another 3 seconds.
iMac G4 1.25GHz running 10.3.4, 512MB RAM, no other software running
But here it's very responsive so without more details I will have trouble to solve.
Do you have the dock always visible ? even if it should not matter
try the following :
- reduce window size
- check all prefs especially international
- look in console for any message
- try to restart
Re: Render Bug related to Emit attribute on Surfaces
once again, can't redo. please provide an example blend so that we can checknorm3dwyer wrote:The render bug that Kerosene noted in the previous build still remains in the OS X version.
-I experienced serious problem with this build and yafray, many crash but the major thing is that is not possible to render any transparence,
I tried with yafray 0.0.6.2 and even the pre 0.0.7.
I don't have interface problems on Mac os X 1.0.3.4 G5 dual 1.8
- In a previous test build there was a very nice pink silouette for selected object when in shaded mode, this feature was so cool, usually it's always difficult to understand the selected object in shaded mode
I tried with yafray 0.0.6.2 and even the pre 0.0.7.
I don't have interface problems on Mac os X 1.0.3.4 G5 dual 1.8
- In a previous test build there was a very nice pink silouette for selected object when in shaded mode, this feature was so cool, usually it's always difficult to understand the selected object in shaded mode
Ton will re-enable this by default, before release. It's the way it is now, due to a little quirk in the code that keeps compatibility between Blender versions .scuozz wrote:- In a previous test build there was a very nice pink silouette for selected object when in shaded mode, this feature was so cool, usually it's always difficult to understand the selected object in shaded mode
I've noticed this too, and I think I can assume it's because of the new fullscreen window. Eg. start Blender and lett it go full screen. Then try and drag the top window border down to reveal the user prefs. Then do Window -> Zoom wto make Blender windowed, then drag the user prefs window border again - it's much faster.akator wrote:I'm experiencing some serious interface responsiveness issues. 4/5 times it takes over 2 seconds for a reaction to input. This includes the 3D windows, buttons, menus... pretty much all of it. Once rotating the 3D view took 8 seconds to respond.
Broken : what is your computer ? VRAM size ?broken wrote:I've noticed this too, and I think I can assume it's because of the new fullscreen window. Eg. start Blender and lett it go full screen. Then try and drag the top window border down to reveal the user prefs. Then do Window -> Zoom wto make Blender windowed, then drag the user prefs window border again - it's much faster.akator wrote:I'm experiencing some serious interface responsiveness issues. 4/5 times it takes over 2 seconds for a reaction to input. This includes the 3D windows, buttons, menus... pretty much all of it. Once rotating the 3D view took 8 seconds to respond.
Does any of you run X11 window ( in the past I had problems with X11 windows overlapping blender)
What I don't understand is that my computer start to be old (Pb G4 867 Mhz) and I don't experiment any slowdown. And I'm known to run 20 apps at same time and have 30 windows open.
you can try also to run blender thru sampler (in develloper apps), this may help to understand where we loose time
This is very inconvenient and I would like to solve this issue, but here it works well :/
PB G4 1.25GHz, 1GB RAM, 64MB VRAM
Actually, on playing with it a bit more, I think it's caused by Blender being behind the dock. When Blender is maximised on startup, it fills the whole screen and sits behind the dock. Even if I resize Blender to a small window, if I drag it down so it's behind the dock, it will slow down as well.
Is there a way to make the fullscreen size = screen height - dock height?
BTW I should have been clearer on the last report - the 'slowness' I mentioned is the time between letting go of the mouse button, and the window space edge appearing in the new location.
Actually, on playing with it a bit more, I think it's caused by Blender being behind the dock. When Blender is maximised on startup, it fills the whole screen and sits behind the dock. Even if I resize Blender to a small window, if I drag it down so it's behind the dock, it will slow down as well.
Is there a way to make the fullscreen size = screen height - dock height?
BTW I should have been clearer on the last report - the 'slowness' I mentioned is the time between letting go of the mouse button, and the window space edge appearing in the new location.
Hoh, very possible. I must look in that. Not sure it's easy.broken wrote:PB G4 1.25GHz, 1GB RAM, 64MB VRAM
Actually, on playing with it a bit more, I think it's caused by Blender being behind the dock. When Blender is maximised on startup, it fills the whole screen and sits behind the dock. Even if I resize Blender to a small window, if I drag it down so it's behind the dock, it will slow down as well.
Is there a way to make the fullscreen size = screen height - dock height?
BTW I should have been clearer on the last report - the 'slowness' I mentioned is the time between letting go of the mouse button, and the window space edge appearing in the new location.
Ok. I can redo that.
My dock being on the side and small, it don't play havoc with the buttons, but the window redraw is indeed slower if dock is up.
this build should solve the problems with overlapping the dock.
Mac Os X RC3
unfortunately, due to the way Os X handle the dock, I was not able to keep start in maximised mode, so now :
- we start keeping a border of 10 pixel from everything including the dock
- the maximised mode is one click away (on the zoom button as you may expect)
Mac Os X RC3
unfortunately, due to the way Os X handle the dock, I was not able to keep start in maximised mode, so now :
- we start keeping a border of 10 pixel from everything including the dock
- the maximised mode is one click away (on the zoom button as you may expect)