I don't have Windows here, I have Linux, with Nvidia's driver, v 460.91.03.
Which version of Hugin is this? I have v2021.0.0.52df0f76c700. Just
tried zooming in on some of my biggest panoramas, didn't encounter any
problems.
On 1/29/22 03:09, [email protected] wrote:
I don't actually know enough about the interface between the display
driver and the level immediately above it to know whether it is even
possible for this bug to be related to the display driver.
If it is related to the display driver, I'm using the closed source
Nvidia 340 driver (the driver for VERY old Nvidia chips) so this could
be an issue almost no one else would ever see. But more likely it is
not display driver related.
I don't have a correct build process on my Windows system (only on my
Fedora 35 system), but I think I can get my changes into a Windows build
that is valid enough for testing the CP dialog. That is on my todo list
for a first sample of how environment specific the bug is, before I ask
anyone else to test. My Windows system has a Radeon card that is a much
newer and more common architecture than the ancient Nvidia card in my
Fedora system.
Even if the bug doesn't matter to most users, a comment in the code
indicated there is a desire to have this same type of code change there,
because if done correctly it would be a performance boost (rather than
my first try that reduces performance).
I also am doing this in conjunction with CP dialog feature improvements
that others seem to be interested in.
On Friday, January 28, 2022 at 10:05:55 PM UTC-5 GnomeNomad wrote:
Could it be related to display driver?
On January 28, 2022 2:10:46 PM HST, "[email protected]"
<[email protected]> wrote:
In my experimentation for 400% and 800% magnification, I am
experiencing a malfunction (entire image displays as black) when
the magnified image is over 134217728 pixels.
I have a bad code change work around for the problem and will
figure out a better code change.
*Who do I ask for the mercurial write access, so I can put the
relevant changes into a branch and try to get some testing by
others?*
I did a lot of stepping through the code looking for the actual
failure point and haven't found it yet, but I expect to.
I think the whole failure might be dependent on the environment
(such as, the bug may be in or below gtk, rather than in hugin
or wxWidgets, and I expect some hugin environments don't use
gtk). I'm even more confident that the performance reduction
(for the CP dialog) caused by my code change and the possible
performance increase (relative to original, not just relative to
a crude fix) likely from doing it right would be highly
dependent on which tools (gtk etc. and maybe even display
driver) are underneath. I can't test enough to do that justice.
The crude fix is replacing the line:
dc.DrawBitmap(bitmap,0,0);
in CPImageCtrl::OnDraw with
if (bitmap.GetWidth() > 2*vSize.GetWidth() && bitmap.GetHeight()
> 2*vSize.GetHeight() )
{
int posX, posY;
GetViewStart(&posX, &posY);
wxBitmap const& subBit =
bitmap.GetSubBitmap(wxRect(posX,posY,vSize.GetWidth(),vSize.GetHeight()));
dc.DrawBitmap(subBit,posX,posY);
} else {
dc.DrawBitmap(bitmap,0,0);
}
--
David W. Jones
[email protected]
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.
--
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/68a1ca4b-f0d9-c093-5ee6-15aa78ae1ccc%40gmail.com.
