[Gothra]

Hi all,

Don't know what is causing the problem since my latest workstation upgrade coincided with the the launch of the Maxwell v1.6.8.0.

My problem is when I tried to open some default Maxwell material and edit it, it is REALLY slow reacting to my mouseclicks, say I wanna click on the Reflectance 0 to change its RGB, it takes like 6 ~ 10 seconds for me to enter the Color Picker screen, that it became hardly acceptable.

Even the color of the pick picker screen is not shown at once when entered, the colors actually "scroll" down to appear, as if its draining some heavy resource from the PC.

The PC I'm using is:

Dell Precision T3400
Windows XP sp2
Q6600 Quadcore 2.4GHz, 4Gb RAM
NVidia Quadro FX1700 512Mb RAM

Speed of modelling calculation is alright, its just the maxwell editor that showing extreme sluggish-ness

Thanks in advance for helps and suggestions.
regards,

Jacky


Takes like 8 second to get from Screenshot 1 to Screenshot 2~

[JDHill]

Hi Jacky,

That seems strange. Have you tried re-booting your machine? If so, and it doesn't help, I would try uninstalling the .Net Framework 2.0 and re-installing it. Let me know if that helps...meanwhile, I'll try to think of some other possibilities.

JD

[Fille]

Hi guys! I have the same problem on my (4 years old) PC...

Philip

[Cadhorn]

That is odd. I don't suppose you're rendering at the same time, with priority set to high? That's the only time i see such sluggishness.

Are you using a dual monitor setup? (if not, ignore the rest of this) I vaguely recall hearing about people having slow response from items on the 2nd monitor, with some video cards in some circumstances. If the sluggishness is happening on a 2nd monitor, try moving the window to your primary monitor and see how it reacts. If it's faster on the 1st monitor then it's probably a video hardware/software issue.

[JDHill]

Yes, one thing is that if you do Material-preview refreshes, there is always the possiblity that the plugin is not able to kill the rendering process properly, so look in your task bar to see if there are possibly any mxcl icons there - if so, right-click and hit 'Quit'. Also, look at Scene Manager > Plug-in Options > Search Paths > Check File Version. What this does (when enabled) is it checks whether or not texture files have been modified since having thumbnails generated. It generates new ones if necessary - but if you have many textures, and/or any of them are on network drives, you can guess that this might slow things down alot.

[Gothra]

Thanks all, but I'm not rendering anything in the background, nor using a dual-monitor setup hehe.

Umm just reinstalled .Net Framework 2.0 but the problem remained.
These graphic card settings matter?

[Maximus3D]

The only thing i noticed is very slow when creating materials inside Rhino with the Maxwell plugin is when you select the colors for your materials, it takes up to 20-30 seconds before the colorpicker window appears. And that can't be correct..

/ Max

[JDHill]

Hi Max,

Is that just the first time it's shown, or every time?

Thanks,

JD

[Maximus3D]

JD, that happens everytime i open the colorpicker from the materialeditor. If it would be only the first time it would be understandable as it caches it window but not everytime..

Btw, love what you did with the Camera LCD feature inside Rhino. Great little feature and very useful! nice touch there JD.

/ Max

[JDHill]

There must be some .Net issue here - the window is only created once, and though it's pretty heavy and I might expect it to have some lag, it shouldn't be bad, and even then it should only be the first time its shown. I don't expect the windows in the plugin to be as quick as other Rhino windows, or MXED, because they are extremely heavy, and everything is custom-drawn, with so many thumbnails, custom cursors, etc. Also, in contrast with MXED, the windows are re-sizable in the plugin, and it does the processing necessary to disable controls which aren't applicable for the given context. That might seem like a simple thing, and it's a generally-requested feature, but it does take alot more processing to accomplish. So, I know it's not the quickest thing out there, but it's not been bad at all for me, and I have just been on a 1.86 GHz processor for the last year - I don't think it's slow, and it should be roughly twice as fast for someone even on a decent old P4.

It's also possible there could be some processor-related issues too - due to the fact that some things happen in the plugin as a result of other things happening in Rhino - and the ultimate source of them is from another thread, the whole UI for the plugin has to be safe for multi-threading. That's a techincal issue, but what it means is that the code can't just say 'show this number' - it may be running on another thread, and it has to basically ask nicely if the thread that owns the UI would please update such-and-such value according to the new data. So, you can see some lags, if the UI thread is already busy doing something and it waits a bit to actually process the request.

But even none of that comes close to explaining waits of 20-30 seconds. Could you please list here the details of your setup (everyone posting that they have problems, I mean) so that I can see if there's anything in common, and maybe I can try to get in touch with Microsoft to see if there are some known issues that need to be worked around.

Thanks,

JD

[Maximus3D]

It's strange, because it was never this slow before in the old plugins i used. Although at that time i were in XP32 with way less ram and a slower cpu. Maybe that's it.. maybe XP64 is the root of all evil because that's what i'm running now.

I also thought of it being Rhino kept the cpu busy by redrawing the models in the viewports but at the time of me picking up the colorpicker non of the viewports were being redrawn so that could pretty much be excluded.

You're probably correct that .NET causes this somehow, but i'm also wondering if any other users had similar slowdowns, have they ?!

Here's my rig..
- Intel Q6600 2,4ghz quadcore cpu
- 8gb Corsair XMS2 DHX 800mhz ram (4x2 config)
- Asus P5WDG2 WS Pro motherboard
- XFX 8800GTS 640mb pci-express card
- Sound Blaster X-Fi Xtreme Audio soundcard
- A bunch of various hdd's
- XP Pro x64 with SP2 and all the latest updates to everything included
- latest hardware drivers, bios all patched, fixed and fully working

/ Max

[JDHill]

Thanks Max, I am on x86 (Vista Business 32bit), so possibly that is a factor...though I've developed some of this on XP Pro x64 on VMWare, and didn't see any problems like this there. There was an SP1 for .Net Framework 2.0 (here's the x64 package: http://www.microsoft.com/downloads/deta ... laylang=en ), though I didn't see anything in the list of fixes that rings a bell. Give it a try though, if you don't already have that installed...let me know if you see an difference.

Thanks,

JD

[Fille]

Hi JD! Here's my "trouble-PC" (on my two other PC:s - my work-PC and my laptop - everything is fine...):

Pentium4 3.40 GHz, 2 Gb RAM, nVidia GF 8600GT
Windows XP SP2 (32 bit)

One more thing. The slowdown is not that pronounced on this "trouble" machine either - only 3...5 seconds, but on the two other the color picker opens instantly...
Thanks!

Philip

[polynurb]

it would be interesting to see if anybody running ATI has the problem, too.
I am on x64 with FireGl, no problems here.

:polynurb

[JDHill]

Thanks for the info Philip - you mentioned the color picker, could you let me know if your issue is mostly regarding that, or is it more just the whole plugin in general? If it's mostly the color picker that's causing a problem, I can move back to using the regular Windows one.

As far as video cards are concerned, I don't think they really are - as far as I know, the .Net Framework, which is what I use to draw things in the plugin, does not really have any idea what kind of video card it runs on - that kind of drawing is all bitmap-based and shouldn't be concerned with the card. Only the SunView globe uses OpenGL, and that is a pretty small/simple control - and it seems to be working fine after a few rare ATI-related issues near the plugin's original release.