I've downloaded the demo of MOHO and like it very much but I'm having the following problems which are making me hesitate to use it:
1. Frequent crashing after working a while. Haven't played with it enough to figure out if there is a pattern.
2. MOHO slows down significantly during use. Quitting the program and reloading my work it runs very quickly again. It then slows down eventually and I have to do the quit/restart again.
3. Menus are very sluggish.
Any thoughts? Anyone else working on a G5 without these problems?
Running Mac OS X 10.3.6 on a G5.
Thanks, Matt
MOHO & OS X 10.3 Problems
Moderators: Víctor Paredes, slowtiger
-
bellissimo
- Posts: 19
- Joined: Thu Aug 05, 2004 12:23 pm
moho sluggish on OSX
I found the same problems working in 10.3 on a 1ghz G4
Moho is unbearably sluggish...it doesnt surprize me that its no better on the G5. Its not the machine...its the code.The previous version of Moho was much faster on my system. All the menus and especially the drawing tools were much more responsive. And yes the effect is cummulative...until it just chokes.This is extremely dissapointing since i held high hopes for version 5. This problem effectively makes it unusable on the mac platform. The new code is obviously not as slick as it used to be.I read in one of the other threads that the development team basically writes the code once and then uses another program(they created) to compile code for all the other platforms. Nice if it works...but the cost seems to be high...not to mention the need for the generic interface.
I guess what puzzles me is that I havent really seen many complaints from mac users...which leads me to believe that most are on PC.
Well I hope that it runs better on PC at least...I tried to demo moho to an animator friend working on a tv show done in flash....while the features were intriguing the performance was not.....so we shut it down and had a coffee instead...hey I tried.....cheers
Moho is unbearably sluggish...it doesnt surprize me that its no better on the G5. Its not the machine...its the code.The previous version of Moho was much faster on my system. All the menus and especially the drawing tools were much more responsive. And yes the effect is cummulative...until it just chokes.This is extremely dissapointing since i held high hopes for version 5. This problem effectively makes it unusable on the mac platform. The new code is obviously not as slick as it used to be.I read in one of the other threads that the development team basically writes the code once and then uses another program(they created) to compile code for all the other platforms. Nice if it works...but the cost seems to be high...not to mention the need for the generic interface.
I guess what puzzles me is that I havent really seen many complaints from mac users...which leads me to believe that most are on PC.
Well I hope that it runs better on PC at least...I tried to demo moho to an animator friend working on a tv show done in flash....while the features were intriguing the performance was not.....so we shut it down and had a coffee instead...hey I tried.....cheers
I don't know if it's just OSX. In Windows ,when I check, I see the memory usage going up and up while doing pretty trivial things within a project. And then things get pretty slow. I suspect there's a pretty fair sized memory leak somewhere in there. Its hard to seal C++ code against it, so I wouldn't be surprised. I always found Macs to be more sensitive to memory issues, so maybe that's why you're noticing it first.
--Brian
--Brian
-
Lost Marble
- Site Admin
- Posts: 2347
- Joined: Tue Aug 03, 2004 6:02 pm
- Location: Scotts Valley, California, USA
- Contact:
This memory leak/slowdown thing is a problem we definitely want to fix. However, the strange thing is that we can't reproduce the problem here.
For those of you that have experienced it, can you tell me more about it? For example, how long is Moho running before you notice the slowdown?
Are you performing any particular operations when the slowdown occurs? For example, are you just using the basic drawing tools, or are you rendering an animation, or playing an animation in Moho, or any other particular thing you can remember?
If you start up Moho and start drawing lines with the freehand tool, just line after line, does Moho start to slow down on you, or do you have to do something else?
Any other information that might help us reproduce the problem would be greatly appreciated.
As far as memory leaks, we use leak-checking software while debugging Moho and there aren't any known leaks at this time, other than a few kilobytes when you quit Moho, but nothing that would grow and grow as you run the program. Early in development (before the first beta), there were some big leaks related to Lua scripts, but these should be all fixed. Of course, since Lua does so many things "automatically", it's hard to track exactly what it's doing behind the scenes, but in our testing here we're just not seeing the memory usage grow and grow.
For those of you that have experienced it, can you tell me more about it? For example, how long is Moho running before you notice the slowdown?
Are you performing any particular operations when the slowdown occurs? For example, are you just using the basic drawing tools, or are you rendering an animation, or playing an animation in Moho, or any other particular thing you can remember?
If you start up Moho and start drawing lines with the freehand tool, just line after line, does Moho start to slow down on you, or do you have to do something else?
Any other information that might help us reproduce the problem would be greatly appreciated.
As far as memory leaks, we use leak-checking software while debugging Moho and there aren't any known leaks at this time, other than a few kilobytes when you quit Moho, but nothing that would grow and grow as you run the program. Early in development (before the first beta), there were some big leaks related to Lua scripts, but these should be all fixed. Of course, since Lua does so many things "automatically", it's hard to track exactly what it's doing behind the scenes, but in our testing here we're just not seeing the memory usage grow and grow.
-
Nolan Scott
- Posts: 396
- Joined: Fri Oct 22, 2004 2:14 am
- Location: Auckland, New Zealand
- Contact:
I am using OSX 10.3.6 700MH iMac G4 768MB RAM.
So far everything works fairly well for me (maybe I don't know better)
My last project had about 120 vector-layers, lots of group-, bone-,
switch- and particle-layers as well, and not much of a slowdown yet -
except one thing: if I put one layer on onionskin and try to change a bone
in that layer Moho becomes unworkable slow, sometimes I even have to
force-quit to get out of it.
Yes Moho still crashes from time to time = SOS (Save Often Sweetie)
Cheers
Nolan
So far everything works fairly well for me (maybe I don't know better)
My last project had about 120 vector-layers, lots of group-, bone-,
switch- and particle-layers as well, and not much of a slowdown yet -
except one thing: if I put one layer on onionskin and try to change a bone
in that layer Moho becomes unworkable slow, sometimes I even have to
force-quit to get out of it.
Yes Moho still crashes from time to time = SOS (Save Often Sweetie)
Cheers
Nolan
Hope you don't mind a non-programmer type jumping in but maybe you can create a simple Lua script to dump a few key parameters to a list and people with affected systems can run it and post the values here?
For example I scanned some Lua pages and I saw mention of stuff like Gcinfo() to get the amount of memory allocated by Lua and the current limit at which garbage collection starts etc so if a few people post maybe you can compare it to systems without the problem and maybe something will stick out as odd -might save you some testing if something is really off.
For example I scanned some Lua pages and I saw mention of stuff like Gcinfo() to get the amount of memory allocated by Lua and the current limit at which garbage collection starts etc so if a few people post maybe you can compare it to systems without the problem and maybe something will stick out as odd -might save you some testing if something is really off.