Several glitches in the display of CP labels and magnifier

[johnfi...@gmail.com]

You might want to jump down to the "TESTING" section below before reading all this concept level content:

In a branch of the Hugin++ fork of Hugin, I fixed a bunch of minor bugs that Hugin has display of CP labels and magnifier.  After I do some other related enhancements and corrections, all that will be merged into the main branch of Hugin++, but I doubt it will ever get merged into Hugin.

I'm writing this because of a few questions I'm curious about, including whether other Hugin users are bothered by these glitches (which bother me enough as a Hugin that I took the time to fix them.  But I'm not a typical user).

Also some of the glitches are Windows specific for reasons I understand, while many others also occur on my Windows system, but not on my Fedora system, but I can't tell whether the difference is due to Windows vs. Linux or is due to the obsolete WxWidgets I'm forced to use on Linux (due to an obsolete video driver I need for an obsolete display card).  So if someone tests any of this on Linux with up-to-date WxWidgets, I'd like to know whether those bugs appear.

A big part of the issue is related to a behavior that I decided to eliminate, because it would be very hard to get exactly right and because I didn't like it anyway:  In Hugin, the positions of CP labels and magnifier are adjusted based on the edges of the visible portion of the scrolled image.  In my version, those positions are set based only on the edges of the whole image.  So a CP that is near the edge of the visible portion but not near that edge of the whole image might have its label or even magnifier off screen.  I think it is perfectly reasonable and expected for those to be off screen:  If the CP's you cared about were that near the visible edge without being near the whole image edge, you would have scrolled to fix that.  Any opinions on that?

In Hugin, the labels visibly jump around at unexpected moments for non obvious reasons because of the many flaws in the code for adjusting based on visible region.  So eliminating that feature eliminates that distracting behavior.  That was very frequent in Windows and happened, but less, in Linux.  But also (maybe Windows only) those jumps interacted with race conditions in the use of WxWidgets, so you could have half the label stay in one position while the other half jumps to a new position.

In Hugin there was code to avoid having the label overlap the magnifier except when you are so close to a corner as to have no choice.  But that code was mostly wrong, so the overlap often occurs when the point is close to an edge but not close to a corner, so the overlap is unnecessary.  I believe my version fixes that (overlaps only when there isa no choice).  Another part of the same Hugin bug loses the label entirely for a CP very near the top left corner of the whole image.  Another part incorrectly decides a 3 digit label (more than 100 CPs connecting two images) doesn't fit near the top or bottom edge, when actually it does fit.

TESTING:

Select a CP, then use the scroll bars to slide that CP out of view then back into view, being careful to keep the mouse on the slidebar and/or outside the image window (not over the image).  On Windows, various different glitches occur depending on the speed at which you scroll to bring it back into view (and also varying based on which of the four edges it was temporarily off of).  When you then move the mouse onto the image, it redisplays, fixing whatever glitches were visible, but also moving labels, which I find annoying.

There is also a more serious bug, Windows only, that I fixed earlier in the same branch:  With the mouse over the image press and hold shift then move the mouse (don't press a mouse button).  Both images are supposed to move with the mouse, and actually do so if very few CPs connect them.  If many CPs connect them (whether they are in the visible portion or not) then the images just jump around a bit with little if any net movement.  How many CPs that takes depends on CPU speed and details of your display, but it is not likely to take any unreasonably large number.

If you get and build my branch, it may be interesting to compare (hugin vs. my branch) for  the behavior of CPs near the edges and corners of the whole image.  That shows lots of subtle wrong behaviors in Hugin that fixed (but only bothered to fix because that was related to the more commonly seen glitches).

I can provide Windows binaries of Hugin++, but it is enough effort to package those, that I won't do so unless asked.  Providing Fedora binaries would be harder and there would be much less point.  Building Hugin++ in Fedora from source code should not be difficult (Bruno answered my questions, making that easy.  I will "pay that forward" if anyone needs any answers for making that easy.  The wiki is obsolete, so you need different -dev packages installed than it says, but if you are just a bit more Fedora competent than I was when I started this, you can easily discover what packages you need).  Building Hugin++ requires building its associated pano13 (rather than using the standard pano13) but it is easy to have both at once (both both forks of pano13 of Hugin).

[Florian Königstein]

I have compiled your code in Windows and uploaded it to:

https://sourceforge.net/projects/huginplusplus/files/development/Hugin++Setup_2021-1.1-Windows-64bit.exe

johnfi...@gmail.com schrieb am Donnerstag, 7. April 2022 um 20:48:40 UTC+2:

In Hugin, the labels visibly jump around at unexpected moments for non obvious reasons because of the many flaws in the code for adjusting based on visible region.  So eliminating that feature eliminates that distracting behavior.  That was very frequent in Windows and happened, but less, in Linux.  But also (maybe Windows only) those jumps interacted with race conditions in the use of WxWidgets, so you could have half the label stay in one position while the other half jumps to a new position.

At the moment I cannot see when the "jump around" in the old version occurs. What I see (in both versions) is that when scrolling via scrollbar so that a CP gets out of view and then scrolling back FAST, sometimes there are parts of the magnifier left at false positions. It seems that the view in not updated correctly.

But both in the old and in your version the label of a CP sometimes seems to overlaps the magnifier.

E.g. move the lower scrollbar left so that the magnifier gets right out of the visible area and then move right again. Then the CP gets visible again, now the label overlapping the magnifier. I hope I really have your latest code version (I'll write you per Mail).

There is also a more serious bug, Windows only, that I fixed earlier in the same branch:  With the mouse over the image press and hold shift then move the mouse (don't press a mouse button).  Both images are supposed to move with the mouse, and actually do so if very few CPs connect them.  If many CPs connect them (whether they are in the visible portion or not) then the images just jump around a bit with little if any net movement.  How many CPs that takes depends on CPU speed and details of your display, but it is not likely to take any unreasonably large number.

 

I can confirm that scrolling while pressing SHIFT is now much better (not jumping around wildly).

[johnfi...@gmail.com]

On Sunday, April 17, 2022 at 10:32:12 AM UTC-4 Florian Königstein wrote:

At the moment I cannot see when the "jump around" in the old version occurs. What I see (in both versions) is that when scrolling via scrollbar so that a CP gets out of view and then scrolling back FAST, sometimes there are parts of the magnifier left at false positions. It seems that the view in not updated correctly.

I think that means you are using the default branch of hugin++, not the "ImproveCPDisplay" branch.

I got busy with non Hugin activities and did not merge my changes into default.  The big merge I did to default of Hugin++ (right before getting too busy) was a bunch of changes Thomas did.

I did not merge the April 9 changes Thomas did, because two of those are badly done mitigations of the problems described in this thread (that were fixed well, I think, in my branch).  Thomas's changes do make the problems much less likely in normal use, but don't fundamentally fix anything, and with a slow CPU (I used my wife's laptop) still have most of the original problems.

I still hope to find time soon to merge "ImproveCPDisplay" to default.

But both in the old and in your version the label of a CP sometimes seems to overlaps the magnifier.

When there is no way to not overlap, it always will.  But ...

 

E.g. move the lower scrollbar left so that the magnifier gets right out of the visible area and then move right again. Then the CP gets visible again, now the label overlapping the magnifier. I hope I really have your latest code version (I'll write you per Mail).

That was fixed in "ImproveCPDisplay".  You probably should wait until after I merge, unless you are really curious.

There is also a more serious bug, Windows only, that I fixed earlier in the same branch:  With the mouse over the image press and hold shift then move the mouse (don't press a mouse button).  Both images are supposed to move with the mouse, and actually do so if very few CPs connect them.  If many CPs connect them (whether they are in the visible portion or not) then the images just jump around a bit with little if any net movement.  How many CPs that takes depends on CPU speed and details of your display, but it is not likely to take any unreasonably large number.

 

I can confirm that scrolling while pressing SHIFT is now much better (not jumping around wildly).

I was misremembering when I typed "same branch". I fixed that earlier in default before the branch, so that correction is included whether you get the branch or not.

[Florian Königstein]

johnfi...@gmail.com schrieb am Sonntag, 17. April 2022 um 18:34:30 UTC+2:

I think that means you are using the default branch of hugin++, not the "ImproveCPDisplay" branch.

Yes, it's the default branch. I was thinking you may have done the merge yet because of your commit on 2022-04-10.

But maybe I should also get more familiar with Mercurial ...

When you will have merged it, I can create new Windows binaries.

[Florian Königstein]

In the Windows binary that I have just uploaded is also an speed improvement in the CP editor tab. In big panoramas with many CPs, it took a lot of time when just one CP was deleted or inserted. In the new version it is significantly faster: For my large pano, it took about 8 seconds before and now it's one second or a bit more.

[johnfi...@gmail.com]

On Sunday, April 17, 2022 at 1:03:09 PM UTC-4 Florian Königstein wrote:

 

When you will have merged it, I can create new Windows binaries.

In case you (or anyone else) wants to try them, I have Windows binaries.

My build method (MINGW64) is different in the layer (not sure what it is properly called) above ABI but below API (of the DLL interface).  So the DLLs I build work with the EXEs I build but the DLLs I build don't work with the EXE built the way you build and vice versa.  So anyone trying my version needs install location my whole set of DLLs and EXEs with location and path distinct from the ordinary install of Hugin or Hugin++

I never tried building the installer (I just use all the files where they get built).  But I'm sure I can figure out how to build it if you want to be able to compare builds or if someone else prefers the MING64 build.