Could wxImage::GetSubImage and then scaling the resulting portion of the original image in CpImgCtl::OnDraw do the trick?
Am 5. Februar 2022 13:04:25 MEZ schrieb "[email protected]" <[email protected]>: >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 > >-- >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/39f8664e-2f4f-48b8-af06-ae2e7ae84a9an%40googlegroups.com. -- 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/9D307265-C7D0-44ED-AC5D-08CC768A4012%40gmail.com.
