On Wed, Mar 2, 2022 at 12:52 PM T. Modes <[email protected]> wrote:
> From an implementation point both classes are very different. They have > only some minor and trivial functions in common - the main part is > completely different implemented. > So it brings only little benefit and on the other side a high risk of > breaking existing functions. > I think you are very wrong about that. But it is your decision. > I don't like your branch because it has performance issues with normal 8 > bit images and massive performance issues with float images as your > confirmed. Furthermore it breaks existing features. > I did not see that you fixed these issues. Instead you want to start from > begin in a new branch... > I'm trying to find a way to cooperate with you. Obviously I haven't figured that out yet. I can't magically fix a performance problem that I can't duplicate. I also can't fix a "broken" feature that so far as I can tell never works even without my changes (I tested on two very different Windows systems and three very different Linux systems). I thought starting from scratch with a different branch is a better way to find a way to make changes you will find acceptable. I really want to include the 400% and 800% zoom choices as well as increasing, rather than disabling, the magnifier at (or above) 200%. The memory saving idea was my attempt to make those changes acceptable to you. But in its current form that isn't going to happen. I could restructure the memory savings so that it only applies to 400% and 800% zoom and make it faster for those two zoom levels (but I can't make it as fast as you say your version is for you). I understand the objection to simply allowing 400% and 800%: On a low ram system the sudden large amount of swapping could make the program look broken rather than just slow. If the memory saving feature automatically switched in for just those zoom levels, then on systems (unlike any I've found) in which the scrolling was originally smooth, the performance flaw of higher zoom would be understandable by almost any user and they could simply decide not to use the higher zoom if the poor scrolling matters that much. On my systems, the scrolling was never smooth and my memory saving feature makes it smoother. So if I coded it to switch on just for 400% and 800% by default, I'd like a hidden option to control that switching point. But the slight improvement in scrolling I get is not that important to me vs having a high zoom with magnifier is necessary for my use of hugin, and I'd like to avoid as much as possible of future merge work taking changes from the official version into my own. I also use the higher zoom in masks, which is one of the reasons I want a common base class, but far from the only reason. -- 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/CALe0Q_%3Dg%2BZLSeXNiJjtTGz_DKEdKTSEQwxCqTC%3D%3D2xa5-kGeAw%40mail.gmail.com.
