It now appears to me that the limitation may be in the device driver (Nvidia). There is quite a lot to this malfunction that seems to me to be almost impossible to fit into the theory that the malfunction is in the driver. But I've stepped through the code down to the point that the image is passed to the driver (XShmPutImage) and it gets there with a valid looking image (and all related values) in the failure case, and it apparently passes the whole (giant) image to the driver along with clipping info, rather than clipping it before passing it.
I still think I can make the change in the way implied by the FIXME comment in CPImageCtrl::OnDraw so that for users who wouldn't see the problem, it would still be a performance boost. *I still don't know the right way to even request the mercurial rights needed to correctly share the changes I want to make. * Failing that, I have a fast enough CPU, if this is for my own use only, I don't care about the small performance cost of fixing this just enough to work vs. the performance increase of a better fix. So for now, I'll go back to adding the features I want to that dialog, rather than further chase this problem. Of course, if you think I misunderstood what I saw in stepping through the code (and the failure is actually elsewhere) I'm open to suggestions. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/b3f1fac9-f607-4da6-ab33-2ea59ed7da93n%40googlegroups.com.
