LDraw.org Discussion Forums

Full Version: Slowness of LPub on Windows 7
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Ever since I was issued a new laptop from work and installed lpub on it, it takes ages to do any kind of render operation. I am guessing there's some security setting in Windows that has to time out every time it invokes the external program to do the render. Anyone know how to fix this?
You aren't the first person to encounter this, but I was never able to track down the source of the problem. (I'm guessing you're using LDView as LPub's renderer; if you're using POV-Ray, then that would indeed be slow.) On some systems, LDView takes a long time to exit once it's done creating the image; I couldn't figure out why, and it didn't do this on my Win 7 computer.

You might try temporarily disabling User Account Control (UAC) to see if it solves the problem. I'm not promoting this as a solution, but if it does solve the problem, it would at least tell me where to look. Having said that, LDView shouldn't do anything that requires admin privileges.
Maybe Windows thinks it requires admin privileges because it writes files? Does it write temp files in a directory that might be protected? It doesn't give me that dialog box to continue when a privileged action is being done, like you see when installing/upgrading software for example.
If all it's doing is writing files to a privileged directory, the files should end up getting written using the shadow file system, so appear to get written to a protected directory, while really getting written somewhere else. I don't know where LPub sends the files generated by LDView; hopefully it either sends them to temp or to somewhere in the user's directory (like AppData). However, if it writes to the LPub directory, I suppose that could create additional slowness for the faked out writes. It might also write somewhere that is a sub-directory of the LDraw directory, so check to see if your LDraw directory itself is in a protected directory.

When I stated that LDView should never need admin rights, I missed pointing out that when it downloads unofficial parts, they always get put into the Unofficial subdirectory of the LDraw directory, so if the LDraw directory itself is somewhere protected, the faked out file writing will happen there also.

One other possible source of the LDView problem is that LDView itself may be incorrectly repeatedly downloading unofficial parts when run from LPub. That would slow things down greatly. I can't remember if I fixed that problem before or after LDView 4.1 was released. You can try this development build of LDView if you want:

Nope, it's still about the same. I didn't time it, but it doesn't seem to be any faster.
OK maybe it's a little faster ... but still a pretty long delay to render.
Just to verify (based on your other post), your tests weren't run with the temp files going in a DropBox directory, were they? I could conceivably see that slowing things down a lot.
Yes, but Dropbox is asynchronous - it's a normal filesystem that Dropbox monitors for changes, not a mounted filesystem.
To reiterate - I downloaded the version you linked to, and ran it in My Documents instead of Dropbox, and had no major improvement in perceived speed. There might have been some improvement but if so it wasn't much.

Also, I was running it under my VPN for work which requires HTTP proxy for Internet access, so it would probably not have been able to contact the server if it were downloading parts. I just tried it without the VPN and no proxy needed, and it's still slow, so I don't think that's it. Anyway, my parts library contains all the parts in the model.

I still think it's something dumb Windows is doing. Maybe it's the 64 bit vs 32 bit thing. Do you have a 64 bit build of LDView?
I even tried it on a FAT-formatted USB-mounted disk, hoping that getting out of NTFS-land would fix it, but it still seems quite slow.
Pages: 1 2