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:
http://www.halibut.com/~tcobbs/ldraw/pri...101-35.zip
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:
http://www.halibut.com/~tcobbs/ldraw/pri...101-35.zip