CP Editor tab 400% and 800% zoom choices

[johnfi...@gmail.com]

On the branch with my previous CP Editor change, I pushed code to provide 400% and 800% zoom choices.

slow and ugly:

Currently, 400% and 800% are slow and ugly.  I have plans for changing both those things.

But I have been using them this way for a while, and for my use having those choices has been much better than not having them.

For my own current use, I later switched from wxIMAGE_QUALITY_NORMAL to wxIMAGE_QUALITY_BILINEAR, which makes it even slower and no longer ugly.  That change did not seem appropriate to include in this commit.

scale and rotate on demand:

Currently, the entire image gets scaled.  If the image is portrait mode, it gets rotated.  Then since my display on Fedora is also portrait mode, the lower level code needs to rotate it back.

The scaling code in wxImage is not terrible efficient for what it does and is not multi-threaded (which would help a lot for big images).

It does not take performance advantages from scale factors being easy rational numbers (N/2**M for tiny N and M).  It shouldn't take such advantage (doesn't apply to enough of its uses) but conceivably hugin should, since our scale comes from a small list of choices.

I don't actually think any of this is the right answer to scaling being slow, but felt the possibilities worth mentioning.

Getting rid of the hugin rotation of an image intended mostly for handing off to a wxDC seems to be practical, so the rotation might not actually be needed and if needed will be done by faster code.  I need to learn a bit more about wxDC to nail down the details.

Usefully delaying the scaling until CPImageCtrl::OnDraw and then not scaling large undisplayed areas, is certainly practical.  But the tools inside wxImage aren't properly exposed to enable that.  So it would involve some reinventing of existing wheels, so I'd rather look for alternatives first.  But ultimately it isn't very much code and could be done better than wxImage did it.

On a related subject, wxImage uses unsigned long for things where uint64_t would be the more obvious choice (a much better choice than  unsigned long on Windows and an equal choice on Linux).  wxImage runs on platforms where  uint64_t would be a very bad choice (for an efficient data type), but I expect hugin never will.  Does anyone reading this know of a platform hugin gets built for on which uint64_t is not a good data type?  At the moment, it seems to be used only in hugin/src/foreign/flann

[T. Modes]

johnfi...@gmail.com schrieb am Samstag, 5. Februar 2022 um 13:04:25 UTC+1:

On the branch with my previous CP Editor change, I pushed code to provide 400% and 800% zoom choices.

Sorry, but I already told you not to do so. You have totally ignored this.

It is not acceptable to use *several* GB!! of RAM (especially for such a minor feature in context of the whole software).

Not everybody has such a powerful PC with a lot of RAM. Hugin should also work for users with less RAM without blocking the computer.

So when committing to the public repository you should also take other users into account - and not only your private opinion/wish.

If you don't want this then do this in your private sandbox, but not in the public repository.

[Gunter Königsmann]

Could wxImage::GetSubImage and then scaling the resulting portion of the original image in CpImgCtl::OnDraw do the trick?

[johnfi...@gmail.com]

On Saturday, February 5, 2022 at 8:35:00 AM UTC-5 gunter.ko...@gmail.com wrote:

Could wxImage::GetSubImage and then scaling the resulting portion of the original image in CpImgCtl::OnDraw do the trick?

Yes.  That does work.  I was intending to do something that works much better than that.  I wanted the feature committed before I start on the performance increase.

At 3 bytes per pixel, and applying to just two of the input images, not the whole panorama, I didn't think memory was the issue I should be worrying about.  But I was expecting to fix the memory issue anyway as a result of fixing the speed.

[T. Modes]

johnfi...@gmail.com schrieb am Samstag, 5. Februar 2022 um 14:49:42 UTC+1:

Yes.  That does work.  I was intending to do something that works much better than that.  I wanted the feature committed before I start on the performance increase.

Don't rely on to be written code. Nobody knows which code you will write - and if this code will work at all.  So this is step 1 - write the optimized code - and the code using the optimized code is step 2 and not vice versa.

At 3 bytes per pixel, and applying to just two of the input images, not the whole panorama, I didn't think memory was the issue I should be worrying about. 

A memory usage of *several* GB is always something to worry.