This requires only a few minutes of your time. The only skill required
is that of clicking away at a target as fast as you can. And the
result may help advance hugin toward release.
2. Fire it up, load a stitching project or start one.
3. Make sure you have plenty of control points between multiple
images, then...
4. turn on your loudspeakers to an Ennio Morricone's western
soundtrack <http://en.wikipedia.org/wiki/ Ennio_Morricone#Leone_film_scores> and get ready to shoot'em!
5. Press F3 to display the control points list. Hold the SHIFT key
down and try to select / deselect as many CPs as fast as you can,
possibly from many different images. Shoot'em fast!
Been there. Done that. And it doesn't crash or I'm just not fast enough. I tried with svn3073 and two projects both having 100+ control points. I tried with Shift select, followed by "Apple" (Ctrl on linux/windows) select and the other way round.
(So on OSX I don't need the "cheat code" to prevent loosing a life and not being able to advance to the next level)
And btw: the F3 does not work on OSX as most other Function keys as they are reserved by OSX.
> This requires only a few minutes of your time. The only skill required > is that of clicking away at a target as fast as you can. And the > result may help advance hugin toward release.
> 5. Press F3 to display the control points list. Hold the SHIFT key > down and try to select / deselect as many CPs as fast as you can, > possibly from many different images. Shoot'em fast!
> 6. Should hugin crash, please add your report to
I could make it crash with a big project (>5000 control points) and a
lot of clicking.
Just wanted to make note two things:
1) It took more than 15 minutes (yes, minutes) to open the control
points window. It's a bit too much.
2) F3 works on Macs, you just have to use Fn+F3 to get F3 instead of
the sys default (mute volume on my Macbook) if you're using a laptop
On 25 Mag, 09:19, "Harry van der Wolf" <hvdw...@gmail.com> wrote:
> Been there. Done that. And it doesn't crash or I'm just not fast enough. I
> tried with svn3073 and two projects both having 100+ control points. I tried
> with Shift select, followed by "Apple" (Ctrl on linux/windows) select and
> the other way round.
> (So on OSX I don't need the "cheat code" to prevent loosing a life and not
> being able to advance to the next level)
> And btw: the F3 does not work on OSX as most other Function keys as they are
> reserved by OSX.
> > This requires only a few minutes of your time. The only skill required
> > is that of clicking away at a target as fast as you can. And the
> > result may help advance hugin toward release.
> > 5. Press F3 to display the control points list. Hold the SHIFT key
> > down and try to select / deselect as many CPs as fast as you can,
> > possibly from many different images. Shoot'em fast!
> > 6. Should hugin crash, please add your report to
On Sun, May 25, 2008 at 2:49 AM, Yuv <goo...@levy.ch> wrote:
> This requires only a few minutes of your time. The only skill required > is that of clicking away at a target as fast as you can. And the > result may help advance hugin toward release.
> 5. Press F3 to display the control points list. Hold the SHIFT key > down and try to select / deselect as many CPs as fast as you can, > possibly from many different images. Shoot'em fast!
> 6. Should hugin crash, please add your report to
> (So on OSX I don't need the "cheat code" to prevent loosing a life and not > being able to advance to the next level)
What soup are you drinking? ah, sorry, I'm confused. These guys live further west on the coast <http://www.asterix.com/> :-)
> And btw: the F3 does not work on OSX as most other Function keys as they are > reserved by OSX.
bummer! All car manufacturers put the clutch pedal on the left of the brake pedal and this feels as if <name_your_favorite_exotic_expensive_luxurious_sports_car> would put it on the right of the gas pedal.
keep on testing, useful crash reports posted in the bug-tracker. Not an easy game, but together we'll all get it to the next level - even if this means filing a bug report for wxWidgets (which I just did):
It is weird anyway. It looks like wxmac doesn't have its major/minor versioning correct. The wxmac in place (and downloaded) is really 2.8.7, but when building you get a 2.8.0.4.dylib. I've been working on that for several days some months ago but without success. Apart from the versioning, the "bleeding through" at that time was much worse. When the bleeding through was finally fixed I forgot about the versioning and never filed a bug report for that, but I think I will now. I checked their website early afternoon but the downloadable tgz is still the same. (Ippei did file a bug report for the "bleeding through" but I heard nothing from it again.)
> Harry van der Wolf wrote: > > (So on OSX I don't need the "cheat code" to prevent loosing a life and > not > > being able to advance to the next level)
> What soup are you drinking? ah, sorry, I'm confused. These guys live > further west on the coast <http://www.asterix.com/> :-)
> > And btw: the F3 does not work on OSX as most other Function keys as they > are > > reserved by OSX.
> bummer! All car manufacturers put the clutch pedal on the left of the > brake pedal and this feels as if > <name_your_favorite_exotic_expensive_luxurious_sports_car> would put it > on the right of the gas pedal.
> keep on testing, useful crash reports posted in the bug-tracker. Not an > easy game, but together we'll all get it to the next level - even if > this means filing a bug report for wxWidgets (which I just did):
> ...I forgot about the versioning and never filed a bug report > for that, but I think I will now. I checked their website early afternoon > but the downloadable tgz is still the same.
yes, please do. they are *very* responsive. I already got a reply on my report (see below):
For an extra-bonus round, can any of you OSX users who can trigger the bug please log in at the URL below and add add a comment with the log?
Please report a bug here rather than giving a link. Try to reproduce the problem in one of the wx samples, because wx developers may not have time to debug your program. You may also have a look at: http://trac.wxwidgets.org/wiki/HowToSubmitTicket
Looking at the reply you already got from developers, it seems that
our reports would not be very useful (it's understandable). I just
hope that this also fixes the incredible slowness that the control
points window has had since forever!
On May 25, 5:51 pm, Yuval Levy <goo...@levy.ch> wrote:
> > ...I forgot about the versioning and never filed a bug report
> > for that, but I think I will now. I checked their website early afternoon
> > but the downloadable tgz is still the same.
> yes, please do. they are *very* responsive. I already got a reply on my
> report (see below):
> For an extra-bonus round, can any of you OSX users who can trigger the
> bug please log in at the URL below and add add a comment with the log?
> Please report a bug here rather than giving a link.
> Try to reproduce the problem in one of the wx samples, because wx
> developers may not have time to debug your program.
> You may also have a look at:
> http://trac.wxwidgets.org/wiki/HowToSubmitTicket
ArAgost wrote: > Looking at the reply you already got from developers, it seems that > our reports would not be very useful (it's understandable). I just > hope that this also fixes the incredible slowness that the control > points window has had since forever!
well, there is an additional reply there! The wxWidgets developers are very responsive. Now we need OSX users to give them what they need: feedback!
I guess the situation is the usual one: not many developers have access to OSX, so they need help. Give it to them, and it will help us too.
> ArAgost wrote: >> Looking at the reply you already got from developers, it seems that >> our reports would not be very useful (it's understandable). I just >> hope that this also fixes the incredible slowness that the control >> points window has had since forever!
> well, there is an additional reply there! The wxWidgets developers are > very responsive. Now we need OSX users to give them what they need: > feedback!
> I guess the situation is the usual one: not many developers have access > to OSX, so they need help. Give it to them, and it will help us too.
They probably want a small piece of code that reproduces the problem. The hugin code is not easily understandable to an outsider and as a wxWidgets developer I would also only look at the bug once I have been provided with a small piece of example code. I expect that due to some differences, list events are produced in a different way and the functions that update the list are called in different order than on the other platforms. The whole dialog probably needs to be rewritten with another approach to avoid the weired slowness under OSX.
Harry, can you provide a debug build of hugin compiled with -g and linked against the debug version of wxWidgets?
> Harry, can you provide a debug build of hugin compiled with -g and linked > against the debug version of wxWidgets?
> ciao > Pablo
Your remark might be a very obvious one for a developer but not for me. You want me to compile with -g. Does that mean for cmake and do I need it in the cmake configure step or during make or as a C-FLAG. And do I only need the -g for hugin or also for wxWidgets?
If you do need a bundle on the other hand I need to find out how to use that in Xcode (and I still need to know what -g is).
And yes, I will do my best to provide a debug build.
> 2008/5/26 Pablo d'Angelo <pablo.dang...@web.de > <mailto:pablo.dang...@web.de>>:
> Harry, can you provide a debug build of hugin compiled with -g and > linked > against the debug version of wxWidgets?
> ciao > Pablo
> Your remark might be a very obvious one for a developer but not for me. > You want me to compile with -g. Does that mean for cmake and do I need > it in the cmake configure step or during make or as a C-FLAG. And do I > only need the -g for hugin or also for wxWidgets?
> If you do need a bundle on the other hand I need to find out how to use > that in Xcode (and I still need to know what -g is).
-g is a gcc options. Sorry no idea where this can be set in XCode. Also, the hugin binary should not be stripped (this saves a lot of space, but removes all function names, so I don't know in which function hugin crashed in the crashlogs).
wxWidgets can be compiled in a debug configuration (not sure how this is done on OSX though, if you use the ./configure approach, it should be one of the configure options). Then in XCode, you need to link against the debug version of the wxWidgets libraries. (and probably define some more preprocessor symbols). On my system wx-config returns the following:
Note to normal OSX users: the builds mentioned below are not for normal purposes. Please download them if you want to help in the bug fixing stage, but do not download them and use them for normal purposes as that is not the intention of this build. Due to debugging info collected the performance might be much slower too.
Please note that the bundle size has grown from 80MB to 276MB and compressed from 23MB to 52MB (tgz) and 66MB (dmg) due to the debug "stuff".
The hugin part and wxMac (WxWidgets) is built with debug and not stripped. The other libs and tools like libjpeg, libtiff, autopano-sift enblend and so on, are not build with debug and are completely stripped.
Below the compilation info: note that the mail-client breaks lines here and there.
> > 2008/5/26 Pablo d'Angelo <pablo.dang...@web.de > > <mailto:pablo.dang...@web.de>>:
> > Harry, can you provide a debug build of hugin compiled with -g and > > linked > > against the debug version of wxWidgets?
> > ciao > > Pablo
> > Your remark might be a very obvious one for a developer but not for me. > > You want me to compile with -g. Does that mean for cmake and do I need > > it in the cmake configure step or during make or as a C-FLAG. And do I > > only need the -g for hugin or also for wxWidgets?
> > If you do need a bundle on the other hand I need to find out how to use > > that in Xcode (and I still need to know what -g is).
> -g is a gcc options. Sorry no idea where this can be set in XCode. Also, > the > hugin binary should not be stripped (this saves a lot of space, but removes > all function names, so I don't know in which function hugin crashed in the > crashlogs).
> wxWidgets can be compiled in a debug configuration (not sure how this is > done on OSX though, if you use the ./configure approach, it should be one > of > the configure options). Then in XCode, you need to link against the debug > version of the wxWidgets libraries. (and probably define some more > preprocessor symbols). On my system wx-config returns the following:
I just saw that it is possible to tell wxWidgets to avoid using the OSX native ListControl, which is causing the extreme slowness of the Control points list window and maybe the multi selection crash. SVN 3091 uses a generic list control, which might fix both. Further tests welcome once a binary of SVN 3091 or later is available.
> On Sun, May 25, 2008 at 2:49 AM, Yuv <goo...@levy.ch> wrote:
> This requires only a few minutes of your time. The only skill required > is that of clicking away at a target as fast as you can. And the > result may help advance hugin toward release.
> 5. Press F3 to display the control points list. Hold the SHIFT key > down and try to select / deselect as many CPs as fast as you can, > possibly from many different images. Shoot'em fast!
> 6. Should hugin crash, please add your report to
huginApp.cpp crashes on #ifdef __WXMAC__ // do not use the native list control on OSX (it is very slow with the control point list window) wxSystemOptions::SetOption(wxT("mac.listctrl.always_use_generic"), 1); #endif
/Users/Shared/development/hugin_related/hugin/mac/../src/hugin1/hugin/hugin App.cpp:111: error: 'wxSystemOptions' has not been declared /Users/Shared/development/hugin_related/hugin/mac/../src/hugin1/hugin/hugin App.cpp:111: error: 'SetOption' was not declared in this scope
Statements in PTWXdlg.cpp (twice) #elsif wxMAJOR_VERSION == 2 should be #elif wxMAJOR_VERSION == 2
> I just saw that it is possible to tell wxWidgets to avoid using the OSX > native ListControl, which is causing the extreme slowness of the Control > points list window and maybe the multi selection crash. > SVN 3091 uses a generic list control, which might fix both. Further tests > welcome once a binary of SVN 3091 or later is available.
> ciao > Pablo
> Michael Galloway schrieb: > > crashed for me. comments submitted to tracker.
> > On Sun, May 25, 2008 at 2:49 AM, Yuv <goo...@levy.ch> wrote:
> > This requires only a few minutes of your time. The only skill > required > > is that of clicking away at a target as fast as you can. And the > > result may help advance hugin toward release.
> > 5. Press F3 to display the control points list. Hold the SHIFT key > > down and try to select / deselect as many CPs as fast as you can, > > possibly from many different images. Shoot'em fast!
> > 6. Should hugin crash, please add your report to
On May 27, 3:07 pm, Pablo d'Angelo <pablo.dang...@web.de> wrote:
> Hi OSX users,
> I just saw that it is possible to tell wxWidgets to avoid using the OSX
> native ListControl, which is causing the extreme slowness of the Control
> points list window and maybe the multi selection crash.
> SVN 3091 uses a generic list control, which might fix both. Further tests
> welcome once a binary of SVN 3091 or later is available.
OSX users, if you can build a version with the wxWidgets also in Debug
mode - there is activity on the wxWidget side of things. They want to
help fix the bug
I saw it and already corrected it myself. I did not patch SVN as I could not solve the other issue. I knew it had to be a header file but I could not find the right one. I assumed that our great guru could solve that almost immediately (and he did: thanks Pablo). I already downloaded 3096.
I already built a debug bundle 3088. I mailed about that one yesterday. I did not have the time to test yet and most possibly neither tonight as I'm never in at Wednesday evening. A second test will be the new 3096 bundle where Pablo changed wxwindows behavior for OSX. I hope to deliver that one early tonight. (I can build remotely via ssh. I takes 2 minutes to get everything going and let it run, but testing takes too much time and need to be done in evening hours).
> On May 27, 3:07 pm, Pablo d'Angelo <pablo.dang...@web.de> wrote: > > Hi OSX users,
> > I just saw that it is possible to tell wxWidgets to avoid using the OSX > > native ListControl, which is causing the extreme slowness of the Control > > points list window and maybe the multi selection crash. > > SVN 3091 uses a generic list control, which might fix both. Further tests > > welcome once a binary of SVN 3091 or later is available.
> OSX users, if you can build a version with the wxWidgets also in Debug > mode - there is activity on the wxWidget side of things. They want to > help fix the bug
Sorry I posted back before reading all the comments in the wxwindows tracker. About the 2766 version where it is actually 3088. There is still a bug in the versioning for Hugin in Xcode. I don't know if it is hugin, or the project or Xcode. For some reason it always build the Info.plist with version 2766. Ippei could not solve it and neither have I (not yet that is). I always manually change the version, but in the hurry of delivering a debug test build I forgot to do that. I will register at the wxwindows tracker and file the bug report for the versioning and try to find Ippei's bug report about the "bleeding through" and if it's not there I will file a new one. Possibly this evening, most possibly tomorrow evening. I'm a bit short in time this week.
> I already built a debug bundle 3088. I mailed about that one yesterday. I > did not have the time to test yet and most possibly neither tonight as I'm > never in at Wednesday evening. > A second test will be the new 3096 bundle where Pablo changed wxwindows > behavior for OSX. I hope to deliver that one early tonight. > (I can build remotely via ssh. I takes 2 minutes to get everything going > and let it run, but testing takes too much time and need to be done in > evening hours).
>> On May 27, 3:07 pm, Pablo d'Angelo <pablo.dang...@web.de> wrote: >> > Hi OSX users,
>> > I just saw that it is possible to tell wxWidgets to avoid using the OSX >> > native ListControl, which is causing the extreme slowness of the Control >> > points list window and maybe the multi selection crash. >> > SVN 3091 uses a generic list control, which might fix both. Further >> tests >> > welcome once a binary of SVN 3091 or later is available.
>> OSX users, if you can build a version with the wxWidgets also in Debug >> mode - there is activity on the wxWidget side of things. They want to >> help fix the bug
I downloaded the debug build of Harry and crashed it (see comment and
log in respective wx issue). So far so good - or bad...
But I wanted to give another comment regarding the "slowness" of the
ListControl. I'd describe it like this: The control itself does not
seem to be slow (it opens right away after pressing View->Control
Points Table) but selecting control points is slow. And to me, it
looks like this is due to the fact that Hugin seems to reload the
(full resolution?) images every time I pick another control point. In
fact, it sometimes seems to load random images before actually loading
the ones containing the cp. This is especially troublesome in case of
multiple selections.
Maybe the following console output makes any sense to someone? I got
this after performing _one_ click/selection inside the Control Points
Table. Hugin then loaded 4 images.
On May 28, 2:00 am, Axel <awag...@gmail.com> wrote:
> Hi,
> I downloaded the debug build of Harry and crashed it (see comment and
> log in respective wx issue). So far so good - or bad...
> But I wanted to give another comment regarding the "slowness" of the
> ListControl. I'd describe it like this: The control itself does not
> seem to be slow[STOP]
How many control points did you have? It seems to me that the delay in
the window opening is proportional to the number of control points.
Can you confirm this?
The wxwidgets developers came with an answer and possibly a solution. See http://trac.wxwidgets.org/ticket/9488?#comment:20 He forgot to mention the code file though but a quick grep -iR showed that it is CPListFrame.cpp (but you might know that from the top of your head I suppose).
@ all others: Some first words: The bundle mentioned here is a debug bundle. Download it only if you want to help us solve this issue. I finally succeeded in creating a complete debug bundle with the tips from the wxmac guys and you can download it from: http://hugin.panotools.org/testing/hugin/DEBUG/3096-DEBUG-wxMAC_ALWAY... It's again a big boy (63MB compressed and 276 MB uncompressed).
The bundle uses the "wxMAC_ALWAYS_USE_GENERIC_LISTCTRL" option and is built with the source suggestion for CPListframe.cpp from the wxmac guys. I created a patch for that and attached it. I don't know whether it can be implemented "generically" or only for OSX (and we first need to test if it works).
That is what I always observe. The more points, the longer it takes the window to come up and the crash likelihood raises exponentially. I do not use the feature for that reason without first saving the project and without dire need. I plan out all my mouse moves ahead of time to minimize the control operations before attempting to use the feature. Sometimes I'll move large projects to a Windows machine just for this operation.
> On May 28, 2:00 am, Axel <awag...@gmail.com> wrote: > > Hi,
> > I downloaded the debug build of Harry and crashed it (see comment and > > log in respective wx issue). So far so good - or bad...
> > But I wanted to give another comment regarding the "slowness" of the > > ListControl. I'd describe it like this: The control itself does not > > seem to be slow[STOP]
> How many control points did you have? It seems to me that the delay in > the window opening is proportional to the number of control points. > Can you confirm this?
|
