Sunday activity for OSX users: shoot'em!

[Yuv]

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.

1. If you don't have it yet installed on your OSX box, grab the latest
version of hugin from <http://panorama.dyndns.org/download.php?id=218>

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!

6. Should hugin crash, please add your report to

<https://sourceforge.net/tracker/index.php?
func=detail&aid=1933391&group_id=77506&atid=550441>

7. If hugin does not crash, report it too before having a deserved
drink at the Saloon.

Thanks ;-)
Yuv

[Harry van der Wolf]

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.

Harry

2008/5/25 Yuv <goo...@levy.ch>:

[ArAgost]

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.
>
> Harry
>
> 2008/5/25 Yuv <goo...@levy.ch>:
>
>
>
> > 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.
>
> > 1. If you don't have it yet installed on your OSX box, grab the latest
> > version of hugin from <http://panorama.dyndns.org/download.php?id=218>
>
> > 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<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!
>
> > 6. Should hugin crash, please add your report to
>
> > <https://sourceforge.net/tracker/index.php?

> > func=detail&aid=1933391&group_id=77506&atid=550441<https://sourceforge.net/tracker/index.php?func=detail&aid=1933391&gro...>

[Michael Galloway]

crashed for me. comments submitted to tracker.

--
-- Michael

[Yuval Levy]

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):

<http://trac.wxwidgets.org/ticket/9488>

Yuv

[Harry van der Wolf]

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

2008/5/25 Yuval Levy <goo...@levy.ch>:

[Yuval Levy]

Harry van der Wolf 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?

thanks
Yuv

Ticket URL: <http://trac.wxwidgets.org/ticket/9488#comment:1>

#9488: libwx_macu-2.8.0.4.0.dylib - crash on multiple clicks
---------------------+------------------------------------------------------
Reporter: yuv | Owner:
Type: defect | Status: infoneeded_new
Priority: normal | Milestone:
Component: wxMac | Version: 2.8.x
Resolution: | Keywords:
Blockedby: | Patch: 0
Blocking: |
---------------------+------------------------------------------------------
Changes (by wojdyr):

* status: new => infoneeded_new

Comment:

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

--
Ticket URL: <http://trac.wxwidgets.org/ticket/9488#comment:1>

[ArAgost]

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!

[Yuval Levy]

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.

<http://trac.wxwidgets.org/ticket/9488#comment:3>

Yuv

[Pablo d'Angelo]

Yuval Levy schrieb:

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?

ciao
Pablo

[Harry van der Wolf]

2008/5/26 Pablo d'Angelo <pablo....@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). 

And yes, I will do my best to provide a debug build.

Harry

[Pablo d'Angelo]

Hi Harry,

Harry van der Wolf wrote:
>
>

> 2008/5/26 Pablo d'Angelo <pablo....@web.de

> <mailto:pablo....@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:

pablo@svalbart:~/src/hugin/trunk/build_gutsy_release$ wx-config --debug=yes
--cxxflags
-I/usr/lib/wx/include/gtk2-unicode-debug-2.8 -I/usr/include/wx-2.8
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -pthread
pablo@svalbart:~/src/hugin/trunk/build_gutsy_release$ wx-config --debug=yes
--libs
-pthread -lwx_gtk2ud_aui-2.8 -lwx_gtk2ud_xrc-2.8 -lwx_gtk2ud_qa-2.8
-lwx_gtk2ud_html-2.8 -lwx_gtk2ud_adv-2.8 -lwx_gtk2ud_core-2.8
-lwx_baseud_xml-2.8 -lwx_baseud_net-2.8 -lwx_baseud-2.8

Probably there is a similar output on OSX, and the XCode project needs to be
changed accordingly.

ciao
Pablo

[Harry van der Wolf]

Hi all,

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.

I just published a hugin debug build. You can find a standard .tgz for the non-OSX users (an OSX application is actually a "special" directory structure, so I needed to tar it instead of gzip/bzip).
I also placed a dmg as for OSX users a dmg is more convenient.
http://hugin.panotools.org/testing/hugin/DEBUG/Hugin3088-debug.tgz
http://hugin.panotools.org/testing/hugin/DEBUG/3088-DEBUG.dmg

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.


WxMac compilation

i386 flags
 env CFLAGS="-arch i386 -march=prescott -mtune=pentium-m -ftree-vectorize -mmacosx-version-min=10.4 -O2 -g -dead_strip" \
  CXXFLAGS="-arch i386 -march=prescott -mtune=pentium-m -ftree-vectorize -mmacosx-version-min=10.4 -O2 -g -dead_strip" \
  CPPFLAGS="-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include" \
  LDFLAGS="-arch i386 -L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib -dead_strip -prebind" \
  ../configure --prefix="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository" --disable-dependency-tracking  \
  --host="i386-apple-darwin8" --exec-prefix=/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386 --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk \
  --enable-monolithic --enable-unicode --with-opengl --enable-compat26 --disable-graphics_ctx \
  --enable-shared --enable-debug --enable-debug_flag --enable-debug_info --enable-debug_gdb \
  --enable-debugreport ;

ppc flags
 env CFLAGS="-arch ppc -mcpu=G3 -mtune=G4 -mmacosx-version-min=10.3 -O2 -g -dead_strip" \
  CXXFLAGS="-arch ppc -mcpu=G3 -mtune=G4 -mmacosx-version-min=10.3 -O2 -g -dead_strip" \
  CPPFLAGS="-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include" \
  LDFLAGS="-arch ppc -L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib -dead_strip -prebind" \
  ../configure --prefix="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository" --disable-dependency-tracking  \
  --host="powerpc-apple-darwin7" --exec-prefix=/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/ppc --with-macosx-sdk=/Developer/SDKs/MacOSX10.3.9.sdk \
  --enable-monolithic --enable-unicode --with-opengl --enable-compat26 --disable-graphics_ctx \
  --enable-shared --enable-debug --enable-debug_flag --enable-debug_info --enable-debug_gdb \
  --enable-debugreport ;


wx-config output for i386 part:  ./wx-config --version-full --selected-config --debug --cppflags --cflags --cxxflags --libs

2.8.7.0
mac-unicode-debug-2.8
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib/wx/include/mac-unicode-debug-2.8 -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib/wx/include/mac-unicode-debug-2.8 -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__
-I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib/wx/include/mac-unicode-debug-2.8 -I/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__
-L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/arch/i386/lib  -arch i386 -L/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib -dead_strip -prebind -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime  -lwx_macud-2.8

(ppc info for wx-config equal except change i386 or ppc )
i386 and ppc library merged with lipo

==========================================================================
Hugin built in Xcode

options
Strip linked product => No
Generate Debug symbols => Yes
Level of debug symbols => Default (default, -g)

If necessary I can also build Hugin with "All symbols (full, -gfull)"

Pablo: Did you have some strategy in mind or is it just testing and file our test results?

Hoi,
Harry

2008/5/26 Pablo d'Angelo <pablo....@web.de>:

[Pablo d'Angelo]

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.

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.
>
> 1. If you don't have it yet installed on your OSX box, grab the latest
> version of hugin from <http://panorama.dyndns.org/download.php?id=218>
>
> 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

> <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!
>
> 6. Should hugin crash, please add your report to
>
> <https://sourceforge.net/tracker/index.php?
> func=detail&aid=1933391&group_id=77506&atid=550441

> <https://sourceforge.net/tracker/index.php?func=detail&aid=1933391&group_id=77506&atid=550441>>

[Harry van der Wolf]

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/huginApp.cpp:111: error: 'wxSystemOptions' has not been declared
/Users/Shared/development/hugin_related/hugin/mac/../src/hugin1/hugin/huginApp.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

Harry

2008/5/27 Pablo d'Angelo <pablo....@web.de>:

[Yuv]

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

http://trac.wxwidgets.org/ticket/9488#comment:6

Yuv

[Guido Kohlmeyer]

Dear Harry,

The wrong #elsif statement is already fixed in SVN 3094.
The build of SVN 3092 failed on Win32 too.

> Statements in PTWXdlg.cpp (twice)
> #elsif wxMAJOR_VERSION == 2
> should be
> #elif wxMAJOR_VERSION == 2
>

Guido

[Harry van der Wolf]

Yes,

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.

Harry

2008/5/28 Guido Kohlmeyer <d...@gekko-design.de>:

[Harry van der Wolf]

Hi Yuv,

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).

Harry

2008/5/28 Yuv <goo...@levy.ch>:

[Harry van der Wolf]

Hi Yuv,

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.

Harry

2008/5/28 Harry van der Wolf <hvd...@gmail.com>:

[Axel]

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 (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.

Image: /Users/axel/Desktop/tests/
20.09.2007-014_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 14 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-023_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 12 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-041_a16,0_t25_i100.jpg
CacheEntry: 1last access: 15 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-041_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 10 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-059_a16,0_t25_i100.jpg
CacheEntry: 2last access: 16 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-059_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 8 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-077_a16,0_t25_i100.jpg
CacheEntry: 2last access: 17 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-077_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 6 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-086_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 4 8bit: 1 16bit: 1 float: 1 mask: 1
purged: 36 MB, memory used for images: 76 MB
Image: /Users/axel/Desktop/tests/
20.09.2007-014_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 14 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-023_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 12 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-041_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 10 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-059_a16,0_t25_i100.jpg
CacheEntry: 1last access: 16 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-059_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 8 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-077_a16,0_t25_i100.jpg
CacheEntry: 2last access: 17 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-077_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 6 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-086_a16,0_t25_i100.jpg
CacheEntry: 2last access: 18 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-086_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 4 8bit: 1 16bit: 1 float: 1 mask: 1
purged: 36 MB, memory used for images: 76 MB
Image: /Users/axel/Desktop/tests/
20.09.2007-014_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 14 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-023_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 12 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-041_a16,0_t25_i100.jpg
CacheEntry: 2last access: 19 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-041_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 10 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-059_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 8 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-077_a16,0_t25_i100.jpg
CacheEntry: 1last access: 17 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-077_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 6 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-086_a16,0_t25_i100.jpg
CacheEntry: 2last access: 18 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-086_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 4 8bit: 1 16bit: 1 float: 1 mask: 1
purged: 36 MB, memory used for images: 76 MB
Image: /Users/axel/Desktop/tests/
20.09.2007-014_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 14 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-023_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 12 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-041_a16,0_t25_i100.jpg
CacheEntry: 2last access: 19 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-041_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 10 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-059_a16,0_t25_i100.jpg
CacheEntry: 2last access: 20 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-059_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 8 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-077_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 6 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/20.09.2007-086_a16,0_t25_i100.jpg
CacheEntry: 1last access: 18 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Users/axel/Desktop/tests/
20.09.2007-086_a16,0_t25_i100.jpg:small
CacheEntry: 1last access: 4 8bit: 1 16bit: 1 float: 1 mask: 1
purged: 36 MB, memory used for images: 76 MB

Sorry, if this is considered off topic...

- Axel

[Yuval Levy]

Axel wrote:
> Sorry, if this is considered off topic...

hi Axel, not off topic at all, and welcome to hugin! Thank you very much
for your feedback.

Yuv

[ArAgost]

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?

[Harry van der Wolf]

@Pablo,

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_ALWAYS_USE_GENERIC_LISTCTRL.dmg.gz
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).

So please test and report back.

Hoi,
Harry

[Allan Seidel]

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.

 

Allan  
 

[Michael Galloway]

i can test this this evening with a pano with couple thousand CP's

-- michael

--
-- Michael

[Harry van der Wolf]

Hi,

I tested it on a 70 2136x2858 images having 2425 Control points. I tried to make it crash in all kinds of ways but it keeps running.
I also used it on a 12 images with 312 Control Points. No crash either.
I think the issue is solved.

Other osx users: Please report your test results too.

Hoi,
Harry

2008/5/29 Michael Galloway <michael.d...@gmail.com>:

[Michael Galloway]

1462 control points, no issue. and its nice to not have to wait 9min for the CP window to arrive :-)

-- michael

--
-- Michael

[Harry van der Wolf]

Hi all,

Opening the window for the control point table for the 70 2136x2858 images project having 2425 Control points with "wxMAC_ALWAYS_USE_GENERIC_LISTCTRL" takes about 1-2 seconds (on my macbook). Selecting sets of CP's and deleting them works fine, so working with the control point table is "comfortable" even with such a huge set.

So, to compare I built another version where I disabled the "wxMAC_ALWAYS_USE_GENERIC_LISTCTRL" setting and used the same
70 2136x2858 images project having 2425 Control points. It now takes 3 minutes (!) to open the window of the controlPoint table. Selecting a set of CP's works fine. Deleting these selected CP's also takes approx 3 minutes, which means that it is ahrdly possible to work with the CP table window. However, it didn't crash but I did not push it to the limits as that is simply not possible with such a performance (and neither did I want to spend the time on that).


The developer Stefan also mentioned some other points and I quote him here:
"I'll try to fix the bleeding through also tomorrow, I'll detail then also another suggestion I have for speeding up things a little bit on the redraw side".

We live in exciting times as you can see.


Harry

2008/5/30 Michael Galloway <michael.d...@gmail.com>:

[Axel]

Hi all,

> >>>>> 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?

After following this thread and the comments on the wxWidgets issue I
now understand that the "slowness" of the 'old' CP list seems to be
dependent on the number of CPs and only reveal itself with hundreds or
thousands of CPs. My projects never exceeded 50 CPs so far....

Regarding the new test-build (debug build + generic listctrl + patch),
I'd like to quote 7zip: "Everything is ok." :-)

To be somewhat more precise:
+ I can't crash it with my test-project anymore
+ the mentioned "loading of random images" before loading/showing the
ones containing the selected CP is gone, meaning it only loads
something if the newly selected CP is not inside the currently visible
pair and if it loads something, than only the images necessary.
Although if memory is not an issue, a little caching of once loaded
images might be nice...
(- the generic list is not as 'slick' as the native list - don't get
me wrong: stability is _way_ more important than 'slilckness' but me
being a Mac user, I'd still wanted to mention it :-))

Exciting times, indeed!

Axel