OpenGL slow because of reloading [was: hugin-0.8.0_beta3 released]

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 | Next >

OpenGL slow because of reloading [was: hugin-0.8.0_beta3 released]

by Seb Perez-D-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Fri, Mar 27, 2009 at 00:50, allard <katan@...> wrote:
>
> Did anybody else notice the OpenGL preview slows down sometimes
> because it reloads the images with every change you make? I've been
> seeing that off and on since the beta2 mark but it does not happen all
> the time. I'm not sure what's going on. At least in this build I was
> seeing it in the only test I did so far.

I have also noticed this (Linux x64). It has happened since the OpenGL
preview was added. It renders the OpenGL preview useless; the only
solution is to close and restart hugin. However this bug is hard to
repeat: it just "happens" after you start optimizing, adding control
points, changing the lens settings, etc.

Cheers,

Seb

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Bruno Postle :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


[reviving this thread] I don't see this problem but I'd like to hear
opinions as to whether this is a critical bug and should block the
0.8.0 release?

On Fri 27-Mar-2009 at 06:42 +0100, Seb Perez-D wrote:

>On Fri, Mar 27, 2009 at 00:50, allard <katan@...> wrote:
>>
>> Did anybody else notice the OpenGL preview slows down sometimes
>> because it reloads the images with every change you make? I've been
>> seeing that off and on since the beta2 mark but it does not happen all
>> the time. I'm not sure what's going on. At least in this build I was
>> seeing it in the only test I did so far.
>
>I have also noticed this (Linux x64). It has happened since the OpenGL
>preview was added. It renders the OpenGL preview useless; the only
>solution is to close and restart hugin. However this bug is hard to
>repeat: it just "happens" after you start optimizing, adding control
>points, changing the lens settings, etc.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by RueiKe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


My experience with this problem on Windows Vista is that it is bad
enough to degrade the overalll user expereince from 0.7.0.  If it does
get released without fixing it, then there should be an option to use
the old preview as a default, so that the problem can be avoided.

Rick

On May 28, 6:12 am, Bruno Postle <br...@...> wrote:

> [reviving this thread] I don't see this problem but I'd like to hear
> opinions as to whether this is a critical bug and should block the
> 0.8.0 release?
>
> On Fri 27-Mar-2009 at 06:42 +0100, Seb Perez-D wrote:
>
>
>
> >On Fri, Mar 27, 2009 at 00:50, allard <ka...@...> wrote:
>
> >> Did anybody else notice the OpenGL preview slows down sometimes
> >> because it reloads the images with every change you make? I've been
> >> seeing that off and on since the beta2 mark but it does not happen all
> >> the time. I'm not sure what's going on. At least in this build I was
> >> seeing it in the only test I did so far.
>
> >I have also noticed this (Linux x64). It has happened since the OpenGL
> >preview was added. It renders the OpenGL preview useless; the only
> >solution is to close and restart hugin. However this bug is hard to
> >repeat: it just "happens" after you start optimizing, adding control
> >points, changing the lens settings, etc.- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Yuval Levy-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


RueiKe wrote:
> My experience with this problem on Windows Vista is that it is bad
> enough to degrade the overalll user expereince from 0.7.0.

+1. My TIFF files are on a network drive. Maybe on a local drive, and
with a larger default cache memory (75MB is kind of ridiculous
nowadays?) it is less of a problem.

The one thing that I'd change is that when the fast preview is closed,
so should the listeners that do the reload.

Yuv

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by slaterson-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On May 27, 3:12 pm, Bruno Postle <br...@...> wrote:

> [reviving this thread] I don't see this problem but I'd like to hear
> opinions as to whether this is a critical bug and should block the
> 0.8.0 release?
>
> On Fri 27-Mar-2009 at 06:42 +0100, Seb Perez-D wrote:
>
> >On Fri, Mar 27, 2009 at 00:50, allard <ka...@...> wrote:
>
> >> Did anybody else notice the OpenGL preview slows down sometimes
> >> because it reloads the images with every change you make? I've been
> >> seeing that off and on since the beta2 mark but it does not happen all
> >> the time. I'm not sure what's going on. At least in this build I was
> >> seeing it in the only test I did so far.
>
> >I have also noticed this (Linux x64). It has happened since the OpenGL
> >preview was added. It renders the OpenGL preview useless; the only
> >solution is to close and restart hugin. However this bug is hard to
> >repeat: it just "happens" after you start optimizing, adding control
> >points, changing the lens settings, etc.

i am experiencing this problem on linux x64.  the opengl preview
window works very well until an image is added or removed from the
project.  if that happens, i've got to either close the preview window
and work without it, or restart hugin.  i've learned to work around
this, it definitely makes the user experience less enjoyable.  :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by allard-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I see this now and then on WinXP, even with much larger cache
settings.
I think it is a very annoying bug, and will lead new users to turn
away from hugin if they experience it in the first few times of use.
If it is possible to fix this within a limited timeframe (1 month or
so)  I would definitely hold up the release.

allard

On May 28, 12:24 am, slaterson <campbell.christop...@...> wrote:

> On May 27, 3:12 pm, Bruno Postle <br...@...> wrote:
>
>
>
> > [reviving this thread] I don't see this problem but I'd like to hear
> > opinions as to whether this is a critical bug and should block the
> > 0.8.0 release?
>
> > On Fri 27-Mar-2009 at 06:42 +0100, Seb Perez-D wrote:
>
> > >On Fri, Mar 27, 2009 at 00:50, allard <ka...@...> wrote:
>
> > >> Did anybody else notice the OpenGL preview slows down sometimes
> > >> because it reloads the images with every change you make? I've been
> > >> seeing that off and on since the beta2 mark but it does not happen all
> > >> the time. I'm not sure what's going on. At least in this build I was
> > >> seeing it in the only test I did so far.
>
> > >I have also noticed this (Linux x64). It has happened since the OpenGL
> > >preview was added. It renders the OpenGL preview useless; the only
> > >solution is to close and restart hugin. However this bug is hard to
> > >repeat: it just "happens" after you start optimizing, adding control
> > >points, changing the lens settings, etc.
>
> i am experiencing this problem on linux x64.  the opengl preview
> window works very well until an image is added or removed from the
> project.  if that happens, i've got to either close the preview window
> and work without it, or restart hugin.  i've learned to work around
> this, it definitely makes the user experience less enjoyable.  :)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Oskar Sander :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I concur with Allard and Yuv,

Cheers
O




2009/6/1 allard <katan@...>

I see this now and then on WinXP, even with much larger cache
settings.
I think it is a very annoying bug, and will lead new users to turn
away from hugin if they experience it in the first few times of use.
If it is possible to fix this within a limited timeframe (1 month or
so)  I would definitely hold up the release.

allard

On May 28, 12:24 am, slaterson <campbell.christop...@...> wrote:
> On May 27, 3:12 pm, Bruno Postle <br...@...> wrote:
>
>
>
> > [reviving this thread] I don't see this problem but I'd like to hear
> > opinions as to whether this is a critical bug and should block the
> > 0.8.0 release?
>
> > On Fri 27-Mar-2009 at 06:42 +0100, Seb Perez-D wrote:
>
> > >On Fri, Mar 27, 2009 at 00:50, allard <ka...@...> wrote:
>
> > >> Did anybody else notice the OpenGL preview slows down sometimes
> > >> because it reloads the images with every change you make? I've been
> > >> seeing that off and on since the beta2 mark but it does not happen all
> > >> the time. I'm not sure what's going on. At least in this build I was
> > >> seeing it in the only test I did so far.
>
> > >I have also noticed this (Linux x64). It has happened since the OpenGL
> > >preview was added. It renders the OpenGL preview useless; the only
> > >solution is to close and restart hugin. However this bug is hard to
> > >repeat: it just "happens" after you start optimizing, adding control
> > >points, changing the lens settings, etc.
>
> i am experiencing this problem on linux x64.  the opengl preview
> window works very well until an image is added or removed from the
> project.  if that happens, i've got to either close the preview window
> and work without it, or restart hugin.  i've learned to work around
> this, it definitely makes the user experience less enjoyable.  :)




--
/O

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Bruno Postle :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Mon 01-Jun-2009 at 07:02 -0700, allard wrote:
>
>I see this now and then on WinXP, even with much larger cache
>settings.

Thomas committed some cache related fixes three days ago (svn 3891).  
I have no idea if this helps, but I intend to do another release
candidate anyway to see where we are at - Since there have been a
lot of other recent changes.

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


OpenGL slow because of reloading

by B. Schnieders :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I first couldn't decide here, but after an evening of
waiting-for-preview-to-close, saving panorama and reloading it, just to
be able to quickly identify some freak images in between the others and
deleting them I vote for fixing this bug as soon as possible, and if
needed waiting with the 0.8 release until it is fixed, as it is - in my
opinion - pretty simple to reproduce this bug (I can't imagine this
won't happen to anyone) by just removing an image while using the
preview or re-optimizing while the preview is closed.

If there might be a fix for this I'll try a recent trunk version by
tomorrow... :)

Benjamin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Gerry Patterson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

Just posting my findings...

I believe I am seeing this problem under linux.  If I load a pano project and open the fast preview window.  There is a slight delay and then I can smoothly move the pano around as excepted.  If I then re-optimize the pano and try to drag around, the performace has dropped considerably.  I profiled  and found that vigra::resizeImageNoInterpolation() from resizeimage.hxx line 279 is using 88% of cpu time when this is happening. Profiling the good case shows the same function using 11%.  I am sure this would drop if I ran the program longer.


So...why is vigra::resizeImageNoInterpolation() getting called so often when dragging the pano  around after re-optimizing?  This is something to look into.  My free time has dropped to zero lately, so it may be a while before I can look at this futher.   But it may point someone in the right direction.

Best Regards,

- Gerry



On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders <benjamin.schnieders@...> wrote:

I first couldn't decide here, but after an evening of
waiting-for-preview-to-close, saving panorama and reloading it, just to
be able to quickly identify some freak images in between the others and
deleting them I vote for fixing this bug as soon as possible, and if
needed waiting with the 0.8 release until it is fixed, as it is - in my
opinion - pretty simple to reproduce this bug (I can't imagine this
won't happen to anyone) by just removing an image while using the
preview or re-optimizing while the preview is closed.

If there might be a fix for this I'll try a recent trunk version by
tomorrow... :)

Benjamin




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Gerry Patterson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hi All,

I believe I have found the problem.  I have commit-ed a fix as of rev 3904.  The fast preview would realize it needed to regenerate textures, but wouldn't store their metadata properly.  So it kept regenerating again, and again....

Best Regards,

- Gerry


On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson <thedeepvoice@...> wrote:
Hello,

Just posting my findings...

I believe I am seeing this problem under linux.  If I load a pano project and open the fast preview window.  There is a slight delay and then I can smoothly move the pano around as excepted.  If I then re-optimize the pano and try to drag around, the performace has dropped considerably.  I profiled  and found that vigra::resizeImageNoInterpolation() from resizeimage.hxx line 279 is using 88% of cpu time when this is happening. Profiling the good case shows the same function using 11%.  I am sure this would drop if I ran the program longer.


So...why is vigra::resizeImageNoInterpolation() getting called so often when dragging the pano  around after re-optimizing?  This is something to look into.  My free time has dropped to zero lately, so it may be a while before I can look at this futher.   But it may point someone in the right direction.

Best Regards,

- Gerry




On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders <benjamin.schnieders@...> wrote:

I first couldn't decide here, but after an evening of
waiting-for-preview-to-close, saving panorama and reloading it, just to
be able to quickly identify some freak images in between the others and
deleting them I vote for fixing this bug as soon as possible, and if
needed waiting with the 0.8 release until it is fixed, as it is - in my
opinion - pretty simple to reproduce this bug (I can't imagine this
won't happen to anyone) by just removing an image while using the
preview or re-optimizing while the preview is closed.

If there might be a fix for this I'll try a recent trunk version by
tomorrow... :)

Benjamin





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Lukáš Jirkovský :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


2009/6/2 Gerry Patterson <thedeepvoice@...>:

>
> Hi All,
>
> I believe I have found the problem.  I have commit-ed a fix as of rev 3904.
> The fast preview would realize it needed to regenerate textures, but
> wouldn't store their metadata properly.  So it kept regenerating again, and
> again....
>
> Best Regards,
>
> - Gerry
>
>
> On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson <thedeepvoice@...>
> wrote:
>>
>> Hello,
>>
>> Just posting my findings...
>>
>> I believe I am seeing this problem under linux.  If I load a pano project
>> and open the fast preview window.  There is a slight delay and then I can
>> smoothly move the pano around as excepted.  If I then re-optimize the pano
>> and try to drag around, the performace has dropped considerably.  I
>> profiled  and found that vigra::resizeImageNoInterpolation() from
>> resizeimage.hxx line 279 is using 88% of cpu time when this is happening.
>> Profiling the good case shows the same function using 11%.  I am sure this
>> would drop if I ran the program longer.
>>
>>
>> So...why is vigra::resizeImageNoInterpolation() getting called so often
>> when dragging the pano  around after re-optimizing?  This is something to
>> look into.  My free time has dropped to zero lately, so it may be a while
>> before I can look at this futher.   But it may point someone in the right
>> direction.
>>
>> Best Regards,
>>
>> - Gerry
>>
>>
>>
>> On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders
>> <benjamin.schnieders@...> wrote:
>>>
>>> I first couldn't decide here, but after an evening of
>>> waiting-for-preview-to-close, saving panorama and reloading it, just to
>>> be able to quickly identify some freak images in between the others and
>>> deleting them I vote for fixing this bug as soon as possible, and if
>>> needed waiting with the 0.8 release until it is fixed, as it is - in my
>>> opinion - pretty simple to reproduce this bug (I can't imagine this
>>> won't happen to anyone) by just removing an image while using the
>>> preview or re-optimizing while the preview is closed.
>>>
>>> If there might be a fix for this I'll try a recent trunk version by
>>> tomorrow... :)
>>>
>>> Benjamin
>>>
>>>
>>
>
>
> >
>

I can't see any slowdown now. Only the crash (but It crashed also with
the svn 3888). I don't know if this crash is there for a long time or
not, because in fact today was the first day I've tried to reproduce
the slowdown which after a while causes crash.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Gerry Patterson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hello,

Crash?  My memory is fuzzy, I don't remember a crash.  Is there a bug report in the tracker on this I can check?

- Gerry

2009/6/2 Lukáš Jirkovský <l.jirkovsky@...>

2009/6/2 Gerry Patterson <thedeepvoice@...>:
>
> Hi All,
>
> I believe I have found the problem.  I have commit-ed a fix as of rev 3904.
> The fast preview would realize it needed to regenerate textures, but
> wouldn't store their metadata properly.  So it kept regenerating again, and
> again....
>
> Best Regards,
>
> - Gerry
>
>
> On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson <thedeepvoice@...>
> wrote:
>>
>> Hello,
>>
>> Just posting my findings...
>>
>> I believe I am seeing this problem under linux.  If I load a pano project
>> and open the fast preview window.  There is a slight delay and then I can
>> smoothly move the pano around as excepted.  If I then re-optimize the pano
>> and try to drag around, the performace has dropped considerably.  I
>> profiled  and found that vigra::resizeImageNoInterpolation() from
>> resizeimage.hxx line 279 is using 88% of cpu time when this is happening.
>> Profiling the good case shows the same function using 11%.  I am sure this
>> would drop if I ran the program longer.
>>
>>
>> So...why is vigra::resizeImageNoInterpolation() getting called so often
>> when dragging the pano  around after re-optimizing?  This is something to
>> look into.  My free time has dropped to zero lately, so it may be a while
>> before I can look at this futher.   But it may point someone in the right
>> direction.
>>
>> Best Regards,
>>
>> - Gerry
>>
>>
>>
>> On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders
>> <benjamin.schnieders@...> wrote:
>>>
>>> I first couldn't decide here, but after an evening of
>>> waiting-for-preview-to-close, saving panorama and reloading it, just to
>>> be able to quickly identify some freak images in between the others and
>>> deleting them I vote for fixing this bug as soon as possible, and if
>>> needed waiting with the 0.8 release until it is fixed, as it is - in my
>>> opinion - pretty simple to reproduce this bug (I can't imagine this
>>> won't happen to anyone) by just removing an image while using the
>>> preview or re-optimizing while the preview is closed.
>>>
>>> If there might be a fix for this I'll try a recent trunk version by
>>> tomorrow... :)
>>>
>>> Benjamin
>>>
>>>
>>
>
>
> >
>

I can't see any slowdown now. Only the crash (but It crashed also with
the svn 3888). I don't know if this crash is there for a long time or
not, because in fact today was the first day I've tried to reproduce
the slowdown which after a while causes crash.




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Lukáš Jirkovský :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


2009/6/2 Gerry Patterson <thedeepvoice@...>:

>
> Hello,
>
> Crash?  My memory is fuzzy, I don't remember a crash.  Is there a bug report
> in the tracker on this I can check?
>
> - Gerry
>
> 2009/6/2 Lukáš Jirkovský <l.jirkovsky@...>
>>
>> 2009/6/2 Gerry Patterson <thedeepvoice@...>:
>> >
>> > Hi All,
>> >
>> > I believe I have found the problem.  I have commit-ed a fix as of rev
>> > 3904.
>> > The fast preview would realize it needed to regenerate textures, but
>> > wouldn't store their metadata properly.  So it kept regenerating again,
>> > and
>> > again....
>> >
>> > Best Regards,
>> >
>> > - Gerry
>> >
>> >
>> > On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson <thedeepvoice@...>
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> Just posting my findings...
>> >>
>> >> I believe I am seeing this problem under linux.  If I load a pano
>> >> project
>> >> and open the fast preview window.  There is a slight delay and then I
>> >> can
>> >> smoothly move the pano around as excepted.  If I then re-optimize the
>> >> pano
>> >> and try to drag around, the performace has dropped considerably.  I
>> >> profiled  and found that vigra::resizeImageNoInterpolation() from
>> >> resizeimage.hxx line 279 is using 88% of cpu time when this is
>> >> happening.
>> >> Profiling the good case shows the same function using 11%.  I am sure
>> >> this
>> >> would drop if I ran the program longer.
>> >>
>> >>
>> >> So...why is vigra::resizeImageNoInterpolation() getting called so often
>> >> when dragging the pano  around after re-optimizing?  This is something
>> >> to
>> >> look into.  My free time has dropped to zero lately, so it may be a
>> >> while
>> >> before I can look at this futher.   But it may point someone in the
>> >> right
>> >> direction.
>> >>
>> >> Best Regards,
>> >>
>> >> - Gerry
>> >>
>> >>
>> >>
>> >> On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders
>> >> <benjamin.schnieders@...> wrote:
>> >>>
>> >>> I first couldn't decide here, but after an evening of
>> >>> waiting-for-preview-to-close, saving panorama and reloading it, just
>> >>> to
>> >>> be able to quickly identify some freak images in between the others
>> >>> and
>> >>> deleting them I vote for fixing this bug as soon as possible, and if
>> >>> needed waiting with the 0.8 release until it is fixed, as it is - in
>> >>> my
>> >>> opinion - pretty simple to reproduce this bug (I can't imagine this
>> >>> won't happen to anyone) by just removing an image while using the
>> >>> preview or re-optimizing while the preview is closed.
>> >>>
>> >>> If there might be a fix for this I'll try a recent trunk version by
>> >>> tomorrow... :)
>> >>>
>> >>> Benjamin
>> >>>
>> >>>
>> >>
>> >
>> >
>> > >
>> >
>>
>> I can't see any slowdown now. Only the crash (but It crashed also with
>> the svn 3888). I don't know if this crash is there for a long time or
>> not, because in fact today was the first day I've tried to reproduce
>> the slowdown which after a while causes crash.
>>
>>
>
>
> >
>

I'm not sure, I'll take a look into bugtracker. Anyway, debugger gave
me this info:

hugin: /home/lukas/DEBUG/test-build/src/hugin-build/src/hugin_base/panodata/Panorama.cpp:1489:
virtual void HuginBase::Panorama::setSrcImage(unsigned int, const
HuginBase::SrcPanoImage&): Assertion `imgNr < state.images.size()'
failed.

So it may not be a crash but an assertion error.

I don't know what exactly triggers it, but it seems that when I open
the GL preview then remove some image, re-optimize it (It's exactly
the same process as what I needed for reproduce slowdown in GL
preview) then open the preview, select drag and play a bit it aborts.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Gerry Patterson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi All,

I have checked in a fix for this as of Rev 3908.  I was able to trigger the error by:

  1. loading project (this project only had 2 images)
  2. opening gl preview
  3. removing image
  4. dragging image
Once I let go of the left mouse button, it would crash every time.

Best Regards,

- Gerry


2009/6/2 Lukáš Jirkovský <l.jirkovsky@...>

2009/6/2 Gerry Patterson <thedeepvoice@...>:
>
> Hello,
>
> Crash?  My memory is fuzzy, I don't remember a crash.  Is there a bug report
> in the tracker on this I can check?
>
> - Gerry
>
> 2009/6/2 Lukáš Jirkovský <l.jirkovsky@...>
>>
>> 2009/6/2 Gerry Patterson <thedeepvoice@...>:
>> >
>> > Hi All,
>> >
>> > I believe I have found the problem.  I have commit-ed a fix as of rev
>> > 3904.
>> > The fast preview would realize it needed to regenerate textures, but
>> > wouldn't store their metadata properly.  So it kept regenerating again,
>> > and
>> > again....
>> >
>> > Best Regards,
>> >
>> > - Gerry
>> >
>> >
>> > On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson <thedeepvoice@...>
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> Just posting my findings...
>> >>
>> >> I believe I am seeing this problem under linux.  If I load a pano
>> >> project
>> >> and open the fast preview window.  There is a slight delay and then I
>> >> can
>> >> smoothly move the pano around as excepted.  If I then re-optimize the
>> >> pano
>> >> and try to drag around, the performace has dropped considerably.  I
>> >> profiled  and found that vigra::resizeImageNoInterpolation() from
>> >> resizeimage.hxx line 279 is using 88% of cpu time when this is
>> >> happening.
>> >> Profiling the good case shows the same function using 11%.  I am sure
>> >> this
>> >> would drop if I ran the program longer.
>> >>
>> >>
>> >> So...why is vigra::resizeImageNoInterpolation() getting called so often
>> >> when dragging the pano  around after re-optimizing?  This is something
>> >> to
>> >> look into.  My free time has dropped to zero lately, so it may be a
>> >> while
>> >> before I can look at this futher.   But it may point someone in the
>> >> right
>> >> direction.
>> >>
>> >> Best Regards,
>> >>
>> >> - Gerry
>> >>
>> >>
>> >>
>> >> On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders
>> >> <benjamin.schnieders@...> wrote:
>> >>>
>> >>> I first couldn't decide here, but after an evening of
>> >>> waiting-for-preview-to-close, saving panorama and reloading it, just
>> >>> to
>> >>> be able to quickly identify some freak images in between the others
>> >>> and
>> >>> deleting them I vote for fixing this bug as soon as possible, and if
>> >>> needed waiting with the 0.8 release until it is fixed, as it is - in
>> >>> my
>> >>> opinion - pretty simple to reproduce this bug (I can't imagine this
>> >>> won't happen to anyone) by just removing an image while using the
>> >>> preview or re-optimizing while the preview is closed.
>> >>>
>> >>> If there might be a fix for this I'll try a recent trunk version by
>> >>> tomorrow... :)
>> >>>
>> >>> Benjamin
>> >>>
>> >>>
>> >>
>> >
>> >
>> > >
>> >
>>
>> I can't see any slowdown now. Only the crash (but It crashed also with
>> the svn 3888). I don't know if this crash is there for a long time or
>> not, because in fact today was the first day I've tried to reproduce
>> the slowdown which after a while causes crash.
>>
>>
>
>
> >
>

I'm not sure, I'll take a look into bugtracker. Anyway, debugger gave
me this info:

hugin: /home/lukas/DEBUG/test-build/src/hugin-build/src/hugin_base/panodata/Panorama.cpp:1489:
virtual void HuginBase::Panorama::setSrcImage(unsigned int, const
HuginBase::SrcPanoImage&): Assertion `imgNr < state.images.size()'
failed.

So it may not be a crash but an assertion error.

I don't know what exactly triggers it, but it seems that when I open
the GL preview then remove some image, re-optimize it (It's exactly
the same process as what I needed for reproduce slowdown in GL
preview) then open the preview, select drag and play a bit it aborts.




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Lukáš Jirkovský :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


2009/6/3 Gerry Patterson <thedeepvoice@...>:

> Hi All,
>
> I have checked in a fix for this as of Rev 3908.  I was able to trigger the
> error by:
>
> loading project (this project only had 2 images)
> opening gl preview
> removing image
> dragging image
>
> Once I let go of the left mouse button, it would crash every time.
>
> Best Regards,
>
> - Gerry
>
>
> 2009/6/2 Lukáš Jirkovský <l.jirkovsky@...>
>>
>> 2009/6/2 Gerry Patterson <thedeepvoice@...>:
>> >
>> > Hello,
>> >
>> > Crash?  My memory is fuzzy, I don't remember a crash.  Is there a bug
>> > report
>> > in the tracker on this I can check?
>> >
>> > - Gerry
>> >
>> > 2009/6/2 Lukáš Jirkovský <l.jirkovsky@...>
>> >>
>> >> 2009/6/2 Gerry Patterson <thedeepvoice@...>:
>> >> >
>> >> > Hi All,
>> >> >
>> >> > I believe I have found the problem.  I have commit-ed a fix as of rev
>> >> > 3904.
>> >> > The fast preview would realize it needed to regenerate textures, but
>> >> > wouldn't store their metadata properly.  So it kept regenerating
>> >> > again,
>> >> > and
>> >> > again....
>> >> >
>> >> > Best Regards,
>> >> >
>> >> > - Gerry
>> >> >
>> >> >
>> >> > On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson
>> >> > <thedeepvoice@...>
>> >> > wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> Just posting my findings...
>> >> >>
>> >> >> I believe I am seeing this problem under linux.  If I load a pano
>> >> >> project
>> >> >> and open the fast preview window.  There is a slight delay and then
>> >> >> I
>> >> >> can
>> >> >> smoothly move the pano around as excepted.  If I then re-optimize
>> >> >> the
>> >> >> pano
>> >> >> and try to drag around, the performace has dropped considerably.  I
>> >> >> profiled  and found that vigra::resizeImageNoInterpolation() from
>> >> >> resizeimage.hxx line 279 is using 88% of cpu time when this is
>> >> >> happening.
>> >> >> Profiling the good case shows the same function using 11%.  I am
>> >> >> sure
>> >> >> this
>> >> >> would drop if I ran the program longer.
>> >> >>
>> >> >>
>> >> >> So...why is vigra::resizeImageNoInterpolation() getting called so
>> >> >> often
>> >> >> when dragging the pano  around after re-optimizing?  This is
>> >> >> something
>> >> >> to
>> >> >> look into.  My free time has dropped to zero lately, so it may be a
>> >> >> while
>> >> >> before I can look at this futher.   But it may point someone in the
>> >> >> right
>> >> >> direction.
>> >> >>
>> >> >> Best Regards,
>> >> >>
>> >> >> - Gerry
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders
>> >> >> <benjamin.schnieders@...> wrote:
>> >> >>>
>> >> >>> I first couldn't decide here, but after an evening of
>> >> >>> waiting-for-preview-to-close, saving panorama and reloading it,
>> >> >>> just
>> >> >>> to
>> >> >>> be able to quickly identify some freak images in between the others
>> >> >>> and
>> >> >>> deleting them I vote for fixing this bug as soon as possible, and
>> >> >>> if
>> >> >>> needed waiting with the 0.8 release until it is fixed, as it is -
>> >> >>> in
>> >> >>> my
>> >> >>> opinion - pretty simple to reproduce this bug (I can't imagine this
>> >> >>> won't happen to anyone) by just removing an image while using the
>> >> >>> preview or re-optimizing while the preview is closed.
>> >> >>>
>> >> >>> If there might be a fix for this I'll try a recent trunk version by
>> >> >>> tomorrow... :)
>> >> >>>
>> >> >>> Benjamin
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> > >
>> >> >
>> >>
>> >> I can't see any slowdown now. Only the crash (but It crashed also with
>> >> the svn 3888). I don't know if this crash is there for a long time or
>> >> not, because in fact today was the first day I've tried to reproduce
>> >> the slowdown which after a while causes crash.
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>> I'm not sure, I'll take a look into bugtracker. Anyway, debugger gave
>> me this info:
>>
>> hugin:
>> /home/lukas/DEBUG/test-build/src/hugin-build/src/hugin_base/panodata/Panorama.cpp:1489:
>> virtual void HuginBase::Panorama::setSrcImage(unsigned int, const
>> HuginBase::SrcPanoImage&): Assertion `imgNr < state.images.size()'
>> failed.
>>
>> So it may not be a crash but an assertion error.
>>
>> I don't know what exactly triggers it, but it seems that when I open
>> the GL preview then remove some image, re-optimize it (It's exactly
>> the same process as what I needed for reproduce slowdown in GL
>> preview) then open the preview, select drag and play a bit it aborts.
>>
>>
>
>
> >
>

Wow, that was fast. Thanks a lot, it would take me much more time to
find where the problem is, because I'm unfamiliar with the preview
code.

Lukáš

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by RueiKe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I have just tried to load and align a project that I had succesfully
processed using SVN3884.  I found that with SVN3906, I get an
"unhandled exception" after choosing "Align" from the assistant tab,
during the "Loading images..." stage.

On Jun 3, 4:33 pm, Lukáš Jirkovský <l.jirkov...@...> wrote:

> 2009/6/3 Gerry Patterson <thedeepvo...@...>:
>
>
>
>
>
> > Hi All,
>
> > I have checked in a fix for this as of Rev 3908.  I was able to trigger the
> > error by:
>
> > loading project (this project only had 2 images)
> > opening gl preview
> > removing image
> > dragging image
>
> > Once I let go of the left mouse button, it would crash every time.
>
> > Best Regards,
>
> > - Gerry
>
> > 2009/6/2 Lukáš Jirkovský <l.jirkov...@...>
>
> >> 2009/6/2 Gerry Patterson <thedeepvo...@...>:
>
> >> > Hello,
>
> >> > Crash?  My memory is fuzzy, I don't remember a crash.  Is there a bug
> >> > report
> >> > in the tracker on this I can check?
>
> >> > - Gerry
>
> >> > 2009/6/2 Lukáš Jirkovský <l.jirkov...@...>
>
> >> >> 2009/6/2 Gerry Patterson <thedeepvo...@...>:
>
> >> >> > Hi All,
>
> >> >> > I believe I have found the problem.  I have commit-ed a fix as of rev
> >> >> > 3904.
> >> >> > The fast preview would realize it needed to regenerate textures, but
> >> >> > wouldn't store their metadata properly.  So it kept regenerating
> >> >> > again,
> >> >> > and
> >> >> > again....
>
> >> >> > Best Regards,
>
> >> >> > - Gerry
>
> >> >> > On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson
> >> >> > <thedeepvo...@...>
> >> >> > wrote:
>
> >> >> >> Hello,
>
> >> >> >> Just posting my findings...
>
> >> >> >> I believe I am seeing this problem under linux.  If I load a pano
> >> >> >> project
> >> >> >> and open the fast preview window.  There is a slight delay and then
> >> >> >> I
> >> >> >> can
> >> >> >> smoothly move the pano around as excepted.  If I then re-optimize
> >> >> >> the
> >> >> >> pano
> >> >> >> and try to drag around, the performace has dropped considerably.  I
> >> >> >> profiled  and found that vigra::resizeImageNoInterpolation() from
> >> >> >> resizeimage.hxx line 279 is using 88% of cpu time when this is
> >> >> >> happening.
> >> >> >> Profiling the good case shows the same function using 11%.  I am
> >> >> >> sure
> >> >> >> this
> >> >> >> would drop if I ran the program longer.
>
> >> >> >> So...why is vigra::resizeImageNoInterpolation() getting called so
> >> >> >> often
> >> >> >> when dragging the pano  around after re-optimizing?  This is
> >> >> >> something
> >> >> >> to
> >> >> >> look into.  My free time has dropped to zero lately, so it may be a
> >> >> >> while
> >> >> >> before I can look at this futher.   But it may point someone in the
> >> >> >> right
> >> >> >> direction.
>
> >> >> >> Best Regards,
>
> >> >> >> - Gerry
>
> >> >> >> On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders
> >> >> >> <benjamin.schnied...@...> wrote:
>
> >> >> >>> I first couldn't decide here, but after an evening of
> >> >> >>> waiting-for-preview-to-close, saving panorama and reloading it,
> >> >> >>> just
> >> >> >>> to
> >> >> >>> be able to quickly identify some freak images in between the others
> >> >> >>> and
> >> >> >>> deleting them I vote for fixing this bug as soon as possible, and
> >> >> >>> if
> >> >> >>> needed waiting with the 0.8 release until it is fixed, as it is -
> >> >> >>> in
> >> >> >>> my
> >> >> >>> opinion - pretty simple to reproduce this bug (I can't imagine this
> >> >> >>> won't happen to anyone) by just removing an image while using the
> >> >> >>> preview or re-optimizing while the preview is closed.
>
> >> >> >>> If there might be a fix for this I'll try a recent trunk version by
> >> >> >>> tomorrow... :)
>
> >> >> >>> Benjamin
>
> >> >> I can't see any slowdown now. Only the crash (but It crashed also with
> >> >> the svn 3888). I don't know if this crash is there for a long time or
> >> >> not, because in fact today was the first day I've tried to reproduce
> >> >> the slowdown which after a while causes crash.
>
> >> I'm not sure, I'll take a look into bugtracker. Anyway, debugger gave
> >> me this info:
>
> >> hugin:
> >> /home/lukas/DEBUG/test-build/src/hugin-build/src/hugin_base/panodata/Panora­ma.cpp:1489:
> >> virtual void HuginBase::Panorama::setSrcImage(unsigned int, const
> >> HuginBase::SrcPanoImage&): Assertion `imgNr < state.images.size()'
> >> failed.
>
> >> So it may not be a crash but an assertion error.
>
> >> I don't know what exactly triggers it, but it seems that when I open
> >> the GL preview then remove some image, re-optimize it (It's exactly
> >> the same process as what I needed for reproduce slowdown in GL
> >> preview) then open the preview, select drag and play a bit it aborts.
>
> Wow, that was fast. Thanks a lot, it would take me much more time to
> find where the problem is, because I'm unfamiliar with the preview
> code.
>
> Lukáš- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Gerry Patterson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

What platform are you using?

So understand, the steps to reproduce this problem are:

  1. load a project .pto file
  2. press the align button on the assistant tab.
Is this correct?

- Gerry


2009/6/3 RueiKe <ruei_ke@...>

I have just tried to load and align a project that I had succesfully
processed using SVN3884.  I found that with SVN3906, I get an
"unhandled exception" after choosing "Align" from the assistant tab,
during the "Loading images..." stage.

On Jun 3, 4:33 pm, Lukáš Jirkovský <l.jirkov...@...> wrote:
> 2009/6/3 Gerry Patterson <thedeepvo...@...>:
>
>
>
>
>
> > Hi All,
>
> > I have checked in a fix for this as of Rev 3908.  I was able to trigger the
> > error by:
>
> > loading project (this project only had 2 images)
> > opening gl preview
> > removing image
> > dragging image
>
> > Once I let go of the left mouse button, it would crash every time.
>
> > Best Regards,
>
> > - Gerry
>
> > 2009/6/2 Lukáš Jirkovský <l.jirkov...@...>
>
> >> 2009/6/2 Gerry Patterson <thedeepvo...@...>:
>
> >> > Hello,
>
> >> > Crash?  My memory is fuzzy, I don't remember a crash.  Is there a bug
> >> > report
> >> > in the tracker on this I can check?
>
> >> > - Gerry
>
> >> > 2009/6/2 Lukáš Jirkovský <l.jirkov...@...>
>
> >> >> 2009/6/2 Gerry Patterson <thedeepvo...@...>:
>
> >> >> > Hi All,
>
> >> >> > I believe I have found the problem.  I have commit-ed a fix as of rev
> >> >> > 3904.
> >> >> > The fast preview would realize it needed to regenerate textures, but
> >> >> > wouldn't store their metadata properly.  So it kept regenerating
> >> >> > again,
> >> >> > and
> >> >> > again....
>
> >> >> > Best Regards,
>
> >> >> > - Gerry
>
> >> >> > On Mon, Jun 1, 2009 at 9:13 PM, Gerry Patterson
> >> >> > <thedeepvo...@...>
> >> >> > wrote:
>
> >> >> >> Hello,
>
> >> >> >> Just posting my findings...
>
> >> >> >> I believe I am seeing this problem under linux.  If I load a pano
> >> >> >> project
> >> >> >> and open the fast preview window.  There is a slight delay and then
> >> >> >> I
> >> >> >> can
> >> >> >> smoothly move the pano around as excepted.  If I then re-optimize
> >> >> >> the
> >> >> >> pano
> >> >> >> and try to drag around, the performace has dropped considerably.  I
> >> >> >> profiled  and found that vigra::resizeImageNoInterpolation() from
> >> >> >> resizeimage.hxx line 279 is using 88% of cpu time when this is
> >> >> >> happening.
> >> >> >> Profiling the good case shows the same function using 11%.  I am
> >> >> >> sure
> >> >> >> this
> >> >> >> would drop if I ran the program longer.
>
> >> >> >> So...why is vigra::resizeImageNoInterpolation() getting called so
> >> >> >> often
> >> >> >> when dragging the pano  around after re-optimizing?  This is
> >> >> >> something
> >> >> >> to
> >> >> >> look into.  My free time has dropped to zero lately, so it may be a
> >> >> >> while
> >> >> >> before I can look at this futher.   But it may point someone in the
> >> >> >> right
> >> >> >> direction.
>
> >> >> >> Best Regards,
>
> >> >> >> - Gerry
>
> >> >> >> On Mon, Jun 1, 2009 at 6:02 PM, Benjamin Schnieders
> >> >> >> <benjamin.schnied...@...> wrote:
>
> >> >> >>> I first couldn't decide here, but after an evening of
> >> >> >>> waiting-for-preview-to-close, saving panorama and reloading it,
> >> >> >>> just
> >> >> >>> to
> >> >> >>> be able to quickly identify some freak images in between the others
> >> >> >>> and
> >> >> >>> deleting them I vote for fixing this bug as soon as possible, and
> >> >> >>> if
> >> >> >>> needed waiting with the 0.8 release until it is fixed, as it is -
> >> >> >>> in
> >> >> >>> my
> >> >> >>> opinion - pretty simple to reproduce this bug (I can't imagine this
> >> >> >>> won't happen to anyone) by just removing an image while using the
> >> >> >>> preview or re-optimizing while the preview is closed.
>
> >> >> >>> If there might be a fix for this I'll try a recent trunk version by
> >> >> >>> tomorrow... :)
>
> >> >> >>> Benjamin
>
> >> >> I can't see any slowdown now. Only the crash (but It crashed also with
> >> >> the svn 3888). I don't know if this crash is there for a long time or
> >> >> not, because in fact today was the first day I've tried to reproduce
> >> >> the slowdown which after a while causes crash.
>
> >> I'm not sure, I'll take a look into bugtracker. Anyway, debugger gave
> >> me this info:
>
> >> hugin:
> >> /home/lukas/DEBUG/test-build/src/hugin-build/src/hugin_base/panodata/Panora­ma.cpp:1489:
> >> virtual void HuginBase::Panorama::setSrcImage(unsigned int, const
> >> HuginBase::SrcPanoImage&): Assertion `imgNr < state.images.size()'
> >> failed.
>
> >> So it may not be a crash but an assertion error.
>
> >> I don't know what exactly triggers it, but it seems that when I open
> >> the GL preview then remove some image, re-optimize it (It's exactly
> >> the same process as what I needed for reproduce slowdown in GL
> >> preview) then open the preview, select drag and play a bit it aborts.
>
> Wow, that was fast. Thanks a lot, it would take me much more time to
> find where the problem is, because I'm unfamiliar with the preview
> code.
>
> Lukáš- Hide quoted text -
>
> - Show quoted text -



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Bruno Postle :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Wed 03-Jun-2009 at 08:29 -0500, Gerry Patterson wrote:
>What platform are you using?
>
>So understand, the steps to reproduce this problem are:
>
>   1. load a project .pto file
>   2. press the align button on the assistant tab.

Rick is using Windows, but possibly this only appears with a zh_TW
locale.

--
Bruno

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by RueiKe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Yes, I am using Vista.  I duplicated this issue in Traditional Chinese
and English, just to be sure it was not a wide character issue.

I loaded a project file from a project I previoulsy complete, 94
images enfused blended pano. Then press align button.  After the
"Levelling panorama" step, it starts "Loading Images" and crashes
about 10 seconds into that after loading a few images.  The Fast
Preview window never opens.

Let me know if you additional details.

Rick

On Jun 3, 9:40 pm, Bruno Postle <br...@...> wrote:

> On Wed 03-Jun-2009 at 08:29 -0500, Gerry Patterson wrote:
>
> >What platform are you using?
>
> >So understand, the steps to reproduce this problem are:
>
> >   1. load a project .pto file
> >   2. press the align button on the assistant tab.
>
> Rick is using Windows, but possibly this only appears with a zh_TW
> locale.
>
> --
> Bruno
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

< Prev | 1 - 2 - 3 | Next >