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 hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/39f8664e-2f4f-48b8-af06-ae2e7ae84a9an%40googlegroups.com.
