I recently rewrote my local change for saving memory in the CP editor, to make it more suitable for committing on the branch with my other changes.
I ran into a bunch of performance side issues (yes, it saves memory, but the savings vs. cost in cpu time are a much trickier topic). I have only one test environment and it is unusual, so I'm hoping for some feedback after I commit the changes on how this affects performance for others. But while I'm still doing some final cleanups pre-commit, it would be great to get some opinions on which simple extra tweaks sound like they would be effective for other environments. The basic change is: I wrote an efficient method for extracting and rotating a subimage from a wxImage, which allowed me to replace work on the whole image when zooming with work on just the visible portion when it is drawn. That results in a big memory saving and a complicated performance change. If you scroll around enough, then eventually the added cpu time would exceed the saved cpu time. But for an interactive application, that typically doesn't matter, because the extra cpu time is distributed across user actions. But a user expects scrolling to be much less sluggish than zooming, which demands more attention on the draw speed. In my own environment (a giant high res display and an ancient graphics card) scrolling the image was painfully slow in my default-branch build and a bit slower in my version. As I relearned linux performance tools (which I had not used since over a decade ago), it took me a while to realize two things: 1) Almost all the sluggishness is CPU time spent in the XORG process that is independent of my change. 2) Of the CPU time within the Hugin process, almost all is creation of the magnifier image. That ought to be such a small thing, that I initially paid no attention to the fact that it wasn't happening at all in the 200% zoom in default branch that I was comparing to my branch. Recomparing at 150%, just so both had a magnifier, the performance difference in scrolling is too tiny to feel (but that could change in another environment). I don't understand the intent of the magnifier current code. I haven't yet learned vigra well enough to really follow the code. For my own use, it would be easier to just call the same extract and rotate function I use for the whole visible portion. But that would conflict with ever merging my code with Thomas's change to warp the magnifier. Simply saving the magnifier result and only computing it when it changes would eliminate most of its contribution to sluggish scrolling. Maybe I should do that before committing the change. Scaling of the visible portion each time that changes is the biggest performance wild card in my change. My faster, but messier, original version mixed that into the efficient extract and rotate code I wrote. Since we support just a few scaling values and each is a rational number made from small integers, it is practical to have that execute far faster than the more general function in wxImage. I never bothered to support .75 and 1.5 in my private copy because I never use them. That and other needed cleanups prevent my committing that speedup for at least weeks. On my AMD 5800X, the wxImage version is good enough for use even within the draw method. But on other CPUs, especially those with less cache, I'm less sure. There is also a giant performance flaw for float images, which would be easy and clean to fix in the image cache code vs. easy and ugly to fix in the control point code. So I haven't yet done either. On my system, all these performance changes are just tiny changes in a basically bad situation, because none of them affect the massive CPU time in the XORG process. So I'm barely better than guessing at what will matter to others with better graphics cards. In some environments, the whole rotate problem and likely the whole scaling problem can be passed all the way down to the graphics card, making this all really smooth. These changes make those changes easier and I'm trying to keep those future changes in mind as I code. But I can't test anything like that on my linux system and I still can't even build on my Windows system. -- 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 hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/c133c1d4-a03f-4aab-a198-d63ad93794ecn%40googlegroups.com.
