Page MenuHome

Bug 5344 returns on new NVidia cards
Closed, ArchivedPublicKNOWN ISSUE

Description

Hi folks,

I thought it was just me at first, but now that I see it's come up before, I thought I'd post this as a new bug report.

My problem is essentially identical to the issue detailed in bug #5344. When I sculpt, every time I put click and release it takes about two seconds for the sculpt cursor to snap back to the mouse cursor and for the window to update. This occurs even if I'm not sculpting, like if I only rotate the view. This happens in both 2.44 and in 2.45 RC2. Interestingly it does not occur in the Silo demo, which seems to have similar sculpting tools to Blender, so I assume it has something to do with how Blender is interacting with stuff through OpenGL (and possibly a driver bug; Apple's kind of screwed the pooch on the drivers for the new MacBook Pros).

Anyway, my current machine:

MacBook Pro 2.2GHz, 2 gig of ram
NVidia 8600M GT video card, 128 meg of ram
Mac OS X 10.4.14 Intel

I use a Wacom tablet for all my work but this was an issue with the mouse as well. I'm happy to do any testing you need (or to run a program to tell you what the OpenGL capabilities of my card are, etc.).

Event Timeline

Assigning to the all knowing sculpt guru

Hi
Try the new update-patch provided by Apple:
http://wsidecar.apple.com/cgi-bin/nph-reg3rdpty2.pl/product=15088&cat=61&platform=osx&method=sa/iMacSoftwareUpdate1.1.dmg

Should stop the misbehaviour.

Greetz...Jens

Sorry, wrong computer-type.
Remembered iMac, but thats not the case wiith you.
Mistake by hurrying....

Jens

Does this slowdown occur in when using retopo? If both of these are slow, it might indicate a problem with the way both tools use the depth buffer.

Good call. Retopo is nigh-unuable because of the pausing. Every time I rotate the scene view the 3D view becomes totally unresponsable for a sec.

But does that mean it's fixable, or that it's a bug in the driver?

I'm fairly sure this is caused by drawview.c line 2740, where the depth buffer is being copied using glReadPixels. This is probably an unaccelerated operation on your hardware+driver. It's possible that the could be made into an accelerated operation by changing some part of the GL state, but since I don't have a MacBook to test on, I can't do much to fix this.

@ Nicholas Bishop: Maybe will U try to fix, send fixed build to Charles Wardlaw and he will test if your effort fixed this bug.

Regards!

@Nicholas: If I had the money to send you for a MBP I totally would, but since I'm a broke punk currently I have a second solution:

Is there anything I can run on my machine that would help you solve this? Some GL Info thing? Barring that, I can get Blender SVN built on my machine I'm sure, so if necessary I could help you do this blind by making small changes and recompiling.

I'd just need direction-- I know next to nothing about OpenGL.

Anything to mention that happens on this issue? Tried to upgrade to 10.5?

(Moved to opengl issues tracker)

@Ton:

The issue persists on 10.5. Interestingly (at least, interesting to me), if I run Blender under Parallels 3, the Win32 Blender's sculpting works just fine. (I have the Win32 one installed because FBX Export also doesn't work on my MBP unless I do it from the command line.)

As I said I'm willing to do what I can to help sort this out, although I'm not much of an OpenGL programmer and little familiarity with the Blender code base.

Has anyone else mentioned anything similar to my problem on MBPs?

Addendum: the system version above is wrong -- should be 10.4.11. Not that it matters.

I finally got the Intel version built from CVS. (I hadn't built a CVS version in a while because of the extra work the Intel build requires.) Built from CVS, everything's working perfectly. I don't know if something in the OpenGL code was changed between 2.45 and now, but it seems cool.

Retopo is also working perfectly.

Incidentally, Scons does not work at all out of the box on Intel. Libiconv isn't included. Also, you have to manually set all the directories, and force it to switch to the lib/darwin-8.x.i386 directory. (Currently, all the logic keeps the directories pointed at the PPC libraries.)

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.

Matt Ebb (broken) changed the task status from Unknown Status to Unknown Status.Mar 26 2010, 6:37 AM