From: Chris C. <chr...@fe...> - 2005-07-20 08:20:48
|
Silvan: > This doc has 250 audio segments, a couple of huge ones and a whole bunch of > little ones. They haven't changed in a month. Why is RG generating audio > previews? Isn't that what these silly .pk files all over my hard disk are > all about? Yes. If they're there and they're newer than the audio file, then they should be used (that may be why you don't see the progress dialog - it only appears when recreating the .pk files). But reading them still takes a certain amount of time, especially if they're long files squished into a highly zoomed canvas, and so the .pk file read is also done in the separate thread. What may be going wrong here (judging from your email - I hadn't noticed the bug report and I don't recall the code) would be if a single thread is being created for every segment. The idea is supposed to be that we have at most one audio preview thread object, with a queue of preview requests, and the segment canvas makes a request and then gets on with life until it's notified that the result is ready. Chris |
From: Chris C. <chr...@fe...> - 2005-07-20 08:40:40
|
G: > Yes, I'll implement the queue as soon as possible. This should be what the audio preview thread already does, it should just be a question of sharing a single thread object among all preview generator objects. Or similar. Sorry, I should have noticed this one when reviewing the code earlier. Chris |
From: Guillaume L. <gla...@te...> - 2005-07-20 09:17:25
|
Chris Cannam wrote: >G: > > >>Yes, I'll implement the queue as soon as possible. >> >> > >This should be what the audio preview thread already does, it should just be a question of sharing a single thread object among all preview generator objects. Or similar. > Apparently I spoke too fast, looking at the code it seems I do create a single instance of the thread (see CompositionView ctor). But still, it would be the most obvious explanation for the problem. -- Guillaume http://telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-07-23 21:48:39
|
On Wednesday 20 July 2005 11:16, Guillaume Laurent wrote: > Chris Cannam wrote: > >G: > >>Yes, I'll implement the queue as soon as possible. > > > >This should be what the audio preview thread already does, it should just > > be a question of sharing a single thread object among all preview > > generator objects. Or similar. > > Apparently I spoke too fast, looking at the code it seems I do create a > single instance of the thread (see CompositionView ctor). But still, it > would be the most obvious explanation for the problem. Quite weird. In trying to reproduce this bug, I load a file with a bunch of audio segs in it (all pointing to the same audio file), and it seems that as soon as AudioPreviewThread::run() exits (it happens right after the 1st preview is computed), the thread remains in a strange state where QThread::running() returns true, even though the thread is really stopped. So the check 'if (!running() start()' in requestPreview() never kicks in, and the thread remains in this silly state. No clue on what could be happening here, apparently QThread's cleanup method which resets its internal state once run() returns is never called. -- Guillaume. http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2005-07-24 05:37:42
|
On Saturday 23 July 2005 05:48 pm, Guillaume Laurent wrote: > Quite weird. In trying to reproduce this bug, I load a file with a bunch of > audio segs in it (all pointing to the same audio file), and it seems that > as soon as AudioPreviewThread::run() exits (it happens right after the 1st > preview is computed), the thread remains in a strange state where > QThread::running() returns true, even though the thread is really stopped. > So the check 'if (!running() start()' in requestPreview() never kicks in, > and the thread remains in this silly state. > > No clue on what could be happening here, apparently QThread's cleanup > method which resets its internal state once run() returns is never called. No explanation, but this is only an obvious problem in HEAD. Incidentally, I goofed and obliterated my 2.4 kernel, and didn't bother to go retrieve it from my backup because I seemed to finally have all my 2.6 problems straightened out (thanks to Chris, basically). This means I'm running with DRI enabled now. It's a world of difference, and I guess I'm going to have to go turn off DRI on purpose so I can continue to see your new code at its worst and hold up the release. Here are current profiler numbers for whatever combination of things is in HEAD at the moment: ->rosegarden 2>&1|grep -- '-> Composition' -> CompositionModelImpl::getRectanglesIn: CPU: 1123 calls, 110ms, 97.9519us/call -> CompositionModelImpl::getRectanglesIn: real: 1123 calls, 0.119297000R, 0.000106231R/call -> CompositionModelImpl::getRectanglesIn: last: CPU: 0ms, real: 0.000684000R -> CompositionModelImpl::computeSegmentOrigin: CPU: 14 calls, 0ms, 0us/call -> CompositionModelImpl::computeSegmentOrigin: real: 14 calls, 0.000608000R, 0.000043429R/call -> CompositionModelImpl::computeSegmentOrigin: last: CPU: 0ms, real: 0.000038000R -> CompositionModelImpl::computeSegmentRect: CPU: 14 calls, 10ms, 714.286us/call -> CompositionModelImpl::computeSegmentRect: real: 14 calls, 0.004804000R, 0.000343143R/call -> CompositionModelImpl::computeSegmentRect: last: CPU: 0ms, real: 0.000310000R -> CompositionView::refreshDrawBuffer: CPU: 1123 calls, 880ms, 783.615us/call -> CompositionView::refreshDrawBuffer: real: 1123 calls, 1.079470000R, 0.000961238R/call -> CompositionView::refreshDrawBuffer: last: CPU: 10ms, real: 0.001359000R -> CompositionView::drawArea: CPU: 1123 calls, 550ms, 489.76us/call -> CompositionView::drawArea: real: 1123 calls, 0.705897000R, 0.000628581R/call -> CompositionView::drawArea: last: CPU: 10ms, real: 0.001106000R Looks to me like these aren't the best numbers I've ever reported... Looks like these are: -> CompositionModelImpl::getRectanglesIn: CPU: 1189 calls, 70ms, 58.873us/call ... -> CompositionView::drawArea: CPU: 1189 calls, 360ms, 302.775us/call There's a lot of subjectivity to this, but I'm starting to think these numbers aren't actually reporting a reliable measure of the user experience. There's no question that what I'm looking at now is absolutely the best I've ever seen this new code. It's basically just normal. Nothing to report, nothing to see here, it just looks normal. No responsiveness problems, smooth action, and if it is a little slower it's not slower enough to notice without doing a side by side comparison. It sure didn't look that way yesterday, before the kernel swap. I'll try with DRI disabled and see if that makes any difference, but not tonight. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Guillaume L. <gla...@te...> - 2005-07-24 07:38:21
|
On Sunday 24 July 2005 07:34, Silvan wrote: > On Saturday 23 July 2005 05:48 pm, Guillaume Laurent wrote: > > > > No clue on what could be happening here, apparently QThread's cleanup > > method which resets its internal state once run() returns is never > > called. > > No explanation, but this is only an obvious problem in HEAD. Not really. I tried loading the file with 1.0 and it failed to display all the previews as well (only some). > I'll try with DRI disabled and see if that makes any difference, but not > tonight. OK. -- Guillaume. http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2005-07-24 20:40:03
|
On Sunday 24 July 2005 03:38 am, Guillaume Laurent wrote: > > I'll try with DRI disabled and see if that makes any difference, but not > > tonight. I'll spare you all the tests I've done. The summary version is that DRI or no DRI makes very little difference. glxgears, for example, runs 10 times faster on software rendering than it did with my old kernel, and 25 times faster with DRI enabled. As far as RG is concerned, pitting HEAD against 1.0 side by side, and doing the canvas scrolling test procedure, I can't see any significant difference between them at all, other than the segment labels (which we need to merge over from the STG branch because Chris's newest idea in this area really looks very good.) None of this explains why I saw such a difference between the old canvas and new on the old kernel. It leaves that question wide open. Why was that? I have no idea. It might not even matter. Anyway, here and now, and I guess for my own part going forward from here, the only thing I have left to really be grumbly about is all the bad stuff happening when I load that project. http://users.adelphia.net/~silvan/zynfidel.rgp (Should be up eventually, it's taking forever to upload. If you want to hear what it's supposed to sound like, load ZynAddSubFX, load the zynfidel/zynfidel.xmz file into ZynAddSubFX, plumb ZynAddSubFX for sound, and plumb Rosegarden to find ZynAddSubFX. But mostly you're just supposed to see how incredibly long it takes from loading before the GUI is ready to be responsive.) -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Silvan <dmm...@us...> - 2005-07-24 15:34:45
Attachments:
yerk.jpg
|
On Sunday 24 July 2005 03:38 am, Guillaume Laurent wrote: > > No explanation, but this is only an obvious problem in HEAD. > > Not really. I tried loading the file with 1.0 and it failed to display all > the previews as well (only some). OK, let me be more clear. Loading this particular audio-segment-rich file only results in a massive CPU load and the appearance that Rosegarden has frozen when loading the file with HEAD. With 1.0 and the STG branch it's completely uneventful and normal. The attached screenshot is the baseline visual state while RG is chewing on this. It occasionally flashes some segments onto the canvas, which then wink back out immediately. Nothing else ever updates at all. The whole process takes somewhere around 40 seconds, and it's impossible to ignore because it hogs everything to the point where I'm left with no choice but to sit there and look at it. If I click on an icon for some other app, it won't get around to responding until RG is done chewing on whatever it's gnawing on, which isn't apparent from looking at the screen, but which only happens (at least this obviously and obnoxiously) when loading this particular file. I've detailed all of this before, I think, including the fact that I created this file with HEAD after the new canvas, loaded it countless times along the way, and this set of symptoms appeared since the end of June. My main point now is that having DRI makes autoscrolling hugely better, but this gross unpleasantness when loading this perfectly good project is still very much evident. (I just reported some disk speed woes in another message, so I'll be clear that I sorted that, and disk speed is back up to the fastest I ever see, which is somewhere around 50 MB/sec.) -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Guillaume L. <gla...@te...> - 2005-07-24 19:03:45
|
On Sunday 24 July 2005 16:59, Silvan wrote: > > OK, let me be more clear. Loading this particular audio-segment-rich file > only results in a massive CPU load and the appearance that Rosegarden has > frozen when loading the file with HEAD. With 1.0 and the STG branch it's > completely uneventful and normal. I believe you, however there seem to be another problem with the audio preview thread, which has been there for a while. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-07-28 17:01:34
|
I've made some changes in the audio preview code which should fix the problem Silvan reported (loading a file with many audio segments makes RG keel over). Please tell me if it improves things. Note that when all previews computing is done, the view should be updated (e.g. load a file, wait a bit and poof, previews are shown). For the moment I've coded that as a call to QWidget::update() (see CompositionView::event()). If the update doesn't happen for you (or only when you scroll or do something which would cause an update), then it's probably yet another instance of update vs. repaint, as it was the case with labels on segments. I tried calling update() first because repaint() is more agressive and (yikes) seems to cause a flicker (don't know why). -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-07-29 22:07:40
|
On Thursday 28 July 2005 19:01, Guillaume Laurent wrote: > I've made some changes in the audio preview code which should fix the > problem Silvan reported (loading a file with many audio segments makes RG > keel over). Please tell me if it improves things. Sorry to be pushy, but these days I can get some work on RG during w-e only. So it would be best if I knew about remaining problems with this code as soon as possible, or else we push the release back another week. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-07-29 22:11:10
|
On Saturday 30 July 2005 00:07, Guillaume Laurent wrote: > On Thursday 28 July 2005 19:01, Guillaume Laurent wrote: > > I've made some changes in the audio preview code which should fix the > > problem Silvan reported (loading a file with many audio segments makes RG > > keel over). Please tell me if it improves things. > > Sorry to be pushy, but these days I can get some work on RG during w-e > only. So it would be best if I knew about remaining problems with this code > as soon as possible, or else we push the release back another week. OK, just got Silvan's reply, switch back to defcon 5 :-) -- Guillaume. http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2005-07-29 22:08:10
|
On Thursday 28 July 2005 01:01 pm, Guillaume Laurent wrote: > If the update doesn't happen for you (or only when you scroll or do > something which would cause an update), then it's probably yet another I didn't thrash the crap out of it, but I did try to find an update problem. It seems OK to me, and it's a HUGE improvement. HUGE!!!!! -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Guillaume L. <gla...@te...> - 2005-07-29 22:12:22
|
On Saturday 30 July 2005 00:08, Silvan wrote: > On Thursday 28 July 2005 01:01 pm, Guillaume Laurent wrote: > > If the update doesn't happen for you (or only when you scroll or do > > something which would cause an update), then it's probably yet another > > I didn't thrash the crap out of it, but I did try to find an update > problem. It seems OK to me, and it's a HUGE improvement. HUGE!!!!! Thanks, nice to know :-). -- Guillaume. http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2005-07-29 23:31:46
|
On Friday 29 July 2005 06:12 pm, Guillaume Laurent wrote: > > I didn't thrash the crap out of it, but I did try to find an update > > problem. It seems OK to me, and it's a HUGE improvement. HUGE!!!!! > Thanks, nice to know :-). Didn't mean to keep you waiting all day. I've been outside most of the day in 10,000% humidity taking care of mowing, weeding, and related chores now that I finally had a day that was less than 40 C. I found some flavor of butterfly caterpillars snacking on my dill weed too, and took pictures of them, and I went for a walk in the woods to pick (and eat!) some exquisite wild berries. It was a good day. Speaking of defcon 5, I wonder how long it will be before people scratch their heads at that. As far as problems, it looks like the audio previews are really OK. I've constructed a couple of tests, and the previews just seem to wink into existence every time. The whole business is much, much better. It doesn't slam the CPU as hard, and Rosegarden no longer appears to be a prop from the Exorcist. That was very successful. However, repeating segments are completely fubared in this build. All those nasty problems you were going to have to work through. I guess that's what you should do this weekend. I can't speak for the other issues I used to have on the old kernel. Everything (ie autoscrolling) otherwise seems pretty much fine, and it shouldn't be too long before we can let this go. We really need some focused testing of the pre-release tarballs this time though. I don't think it will do to take the express train route. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Chris C. <ca...@al...> - 2005-07-30 10:19:09
|
Tried with my big test file & it crashed. Trace below. Haven't managed to get it to do it again yet. Behaviour somewhat different from 1.0 also (1.0 puts each preview up as it's ready, current CVS all at once). Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1234648224 (LWP 7566)] [New Thread -1241080912 (LWP 7588)] [Thread debugging using libthread_db enabled] [New Thread -1234648224 (LWP 7566)] [New Thread -1241080912 (LWP 7588)] [Thread debugging using libthread_db enabled] [New Thread -1234648224 (LWP 7566)] [New Thread -1241080912 (LWP 7588)] [KCrash handler] #4 0x080f26f6 in CompositionModelImpl::makeAudioPreviewRects (this=0x8bb0910, apRects=0x8bc7234, segment=0x8bd5100, clipRect=@0xbfffdee0) at gui/compositionview.cpp:451 #5 0x080f1613 in CompositionModelImpl::getRectanglesIn (this=0x8bb0910, rect=@0xbfffdee0, npData=0x8bc7240, apData=0x8bc7234) at gui/compositionview.cpp:250 #6 0x080f75e9 in CompositionView::drawArea (this=0x8bc7080, p=0xbfffdef0, clipRect=@0xbfffdee0) at gui/compositionview.cpp:1531 #7 0x080f74b8 in CompositionView::refreshDrawBuffer (this=0x8bc7080, rect=@0xbfffe4dc) at gui/compositionview.cpp:1502 #8 0x080f72c2 in CompositionView::viewportPaintEvent (this=0x8bc7080, e=0xbfffe4d0) at gui/compositionview.cpp:1481 #9 0xb79d30c4 in QScrollView::eventFilter () from /usr/lib/libqt-mt.so.3 #10 0xb78bb04e in QObject::activate_filters () from /usr/lib/libqt-mt.so.3 #11 0xb78baf7c in QObject::event () from /usr/lib/libqt-mt.so.3 #12 0xb78f3aaf in QWidget::event () from /usr/lib/libqt-mt.so.3 #13 0xb7860e1f in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #14 0xb786041e in QApplication::notify () from /usr/lib/libqt-mt.so.3 #15 0xb7205e43 in KApplication::notify () from /usr/lib/libkdecore.so.4 #16 0xb782a9b7 in QWidget::repaint () from /usr/lib/libqt-mt.so.3 #17 0xb7861c45 in QApplication::sendPostedEvents () from /usr/lib/libqt-mt.so.3 #18 0xb7861a96 in QApplication::sendPostedEvents () from /usr/lib/libqt-mt.so.3 #19 0xb780a1cd in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #20 0xb787327f in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #21 0x083575ae in RosegardenApplication::refreshGUI (this=0xbffff880, maxTime=50) at gui/rgapplication.cpp:94 #22 0x084954b9 in RosegardenProgressDialog::processEvents () at gui/widgets.cpp:293 #23 0x083a06a7 in RosegardenGUIApp::initView (this=0x87e17d0) at gui/rosegardengui.cpp:1415 #24 0x083a0b4c in RosegardenGUIApp::setDocument (this=0x87e17d0, newDocument=0x8b92530) at gui/rosegardengui.cpp:1500 #25 0x083a0e73 in RosegardenGUIApp::openFile (this=0x87e17d0, filePath= {static null = {static null = <same as static member of an already seen type>, d = 0x86fa070, static shared_null = 0x86fa070}, d = 0x8c5b3f0, static shared_null = 0x86fa070}, type=ImportCheckType) at gui/rosegardengui.cpp:1551 #26 0x083c266d in RosegardenGUIApp::openFile (this=0x87e17d0, filePath=) at rosegardengui.h:140 #27 0x083a4324 in RosegardenGUIApp::openURL (this=0x87e17d0, url=@0xbfffea80) at gui/rosegardengui.cpp:2044 #28 0x083a498a in RosegardenGUIApp::slotFileOpen (this=0x87e17d0) at gui/rosegardengui.cpp:2081 #29 0x083bf542 in RosegardenGUIApp::qt_invoke (this=0x87e17d0, _id=77, _o=0xbfffebd0) at rosegardengui.moc:759 #30 0xb78bd71c in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #31 0xb78bd544 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #32 0xb74a2dab in KAction::activated () from /usr/lib/libkdeui.so.4 #33 0xb74a277f in KAction::slotActivated () from /usr/lib/libkdeui.so.4 #34 0xb74a2fb1 in KAction::qt_invoke () from /usr/lib/libkdeui.so.4 #35 0xb78bd71c in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #36 0xb7bfc62a in QSignal::signal () from /usr/lib/libqt-mt.so.3 #37 0xb78d791d in QSignal::activate () from /usr/lib/libqt-mt.so.3 #38 0xb79c50d9 in QPopupMenu::mouseReleaseEvent () from /usr/lib/libqt-mt.so.3 #39 0xb78f3b37 in QWidget::event () from /usr/lib/libqt-mt.so.3 #40 0xb7860e1f in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #41 0xb7860514 in QApplication::notify () from /usr/lib/libqt-mt.so.3 #42 0xb7205e43 in KApplication::notify () from /usr/lib/libkdecore.so.4 #43 0xb77f51a1 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3 #44 0xb77f323e in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #45 0xb780a254 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #46 0xb78731d8 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #47 0xb7873088 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #48 0xb7861071 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #49 0x081fedcb in main (argc=1, argv=0xbffffa44) at gui/main.cpp:630 |
From: Chris C. <ca...@al...> - 2005-07-30 11:09:53
|
On Saturday 30 Jul 2005 11:18, Chris Cannam wrote: > Behaviour somewhat different from 1.0 also (1.0 puts each preview up > as it's ready, current CVS all at once). Also, it scrolls my big test file quite a bit slower than 1.0 (or rather than the STG branch, which is what I'm actually comparing against and I suggest you compare against as well). The "old" canvas seems to have a lazier refresh -- you scroll quickly and you get lots of empty background that fills itself in with a rather flickery but vaguely effective action. With the new one you see very little empty un-refreshed background, but there's too much lag. This is on a fast machine, so I'd call it a problem. btw there is another difference between the STG branch and HEAD -- STG uses logarithmic levels for previews, so the previews themselves look different. I'm going to bring that across to HEAD once I've optimised it a bit more. Chris |
From: Silvan <dmm...@us...> - 2005-07-30 13:18:33
|
On Saturday 30 July 2005 07:09 am, Chris Cannam wrote: > Also, it scrolls my big test file quite a bit slower than 1.0 (or rather > than the STG branch, which is what I'm actually comparing against and I > suggest you compare against as well). I emailed him off-list with a finding that audio segments seem to bog down scrolling, whether previews are visible or not. I have a huge all MIDI test file, and everything seems more or less fine. Add one fairly big audio segment to that, turn previews and labels off, and it still cuts scrolling performance sharply. More audio seems to make it progressively worse, and an audio-heavy file (Zynfidel) is just short of impossible to work with. I'll add another finding. Deleting the audio tracks from one of these boggy files makes an immediate and dramatic positive difference, then undoing the deletion makes an immediate negative difference. I really don't think I'm dreaming this at all. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ |
From: Guillaume L. <gla...@te...> - 2005-07-30 17:44:39
|
On Saturday 30 July 2005 15:18, Silvan wrote: > > I emailed him off-list with a finding that audio segments seem to bog down > scrolling, whether previews are visible or not. I have a huge all MIDI > test file, and everything seems more or less fine. Add one fairly big > audio segment to that, turn previews and labels off, and it still cuts > scrolling performance sharply. More audio seems to make it progressively > worse, and an audio-heavy file (Zynfidel) is just short of impossible to > work with. I downloaded this file, it scrolls fine here. :-( *sigh*. I'll try looking for bottlenecks. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-07-30 15:42:27
|
On Saturday 30 July 2005 01:31, Silvan wrote: > > However, repeating segments are completely fubared in this build. All > those nasty problems you were going to have to work through. These should be fixed now. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-07-30 17:28:22
|
On Saturday 30 July 2005 12:18, Chris Cannam wrote: > Tried with my big test file & it crashed. > Trace below. Haven't managed to get it to do it again yet. Looks like a problem with how the size of the peak values array is computed : int position = int(channels * i * sampleScaleFactor); if (position < 0) continue; if (position >= values.size() - channels) break; if (channels == 1) { h1 = values[position++]; <<<<---- crashes here > Behaviour somewhat different from 1.0 also (1.0 puts each preview up as > it's ready, current CVS all at once). I did this because calling repaint() for every preview was causing too much flicker, so I ended up calling it only when the preview queue was emptied. However now that it seems calling update() works, I can get the old behavior back if you prefer. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2005-07-30 17:51:30
|
On Saturday 30 Jul 2005 18:28, Guillaume Laurent wrote: > Looks like a problem with how the size of the peak values array is > computed : If you look at lines 446 - 451 (451 is where it crashes): 446 if (position < 0) continue; 447 if (position >= values.size() - channels) break; 448 449 if (channels == 1) { 450 451 h1 = values[position++]; So we know that at line 451 (before the post-increment), position >= 0 and position < size() - 1. That guarantees we're looking up a valid vector element, except in one case -- when the vector is empty. The old code has an explicit check for this, the new code doesn't. If values is empty, "values.size() - channels" will wrap around silently, because values.size() is unsigned. (How apposite, following that thread about unsigned versus signed ints the other day!) > I did this because calling repaint() for every preview was causing > too much flicker, so I ended up calling it only when the preview > queue was emptied. However now that it seems calling update() works, > I can get the old behavior back if you prefer. Yes, I prefer -- AudioPreviewThread is clever enough to try to do smaller previews first, precisely to accommodate incremental refresh. Chris |
From: Guillaume L. <gla...@te...> - 2005-07-30 21:20:23
|
On Saturday 30 July 2005 19:50, Chris Cannam wrote: > > That guarantees we're looking up a valid vector element, except in one > case -- when the vector is empty. The old code has an explicit check > for this, the new code doesn't. Check added. > > I did this because calling repaint() for every preview was causing > > too much flicker, so I ended up calling it only when the preview > > queue was emptied. However now that it seems calling update() works, > > I can get the old behavior back if you prefer. > > Yes, I prefer -- AudioPreviewThread is clever enough to try to do > smaller previews first, precisely to accommodate incremental refresh. Change done (and I just happened to properly read the 1-line long doc of repaint() to learn that it does erase prior to repainting, and that passing it 'false' will counter that. Duh.) So no flicker, nice updates. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2005-07-30 17:49:01
|
On Saturday 30 July 2005 13:09, Chris Cannam wrote: > > Also, it scrolls my big test file quite a bit slower than 1.0 (or rather > than the STG branch, which is what I'm actually comparing against and I > suggest you compare against as well). I have a 1.0 ready. Are there any differences with regard to the seg canvas between 1.0 and STG that are worth the checkout & recompile ? > The "old" canvas seems to have a lazier refresh -- you scroll quickly > and you get lots of empty background that fills itself in with a rather > flickery but vaguely effective action. With the new one you see very > little empty un-refreshed background, but there's too much lag. This > is on a fast machine, so I'd call it a problem. I've taken a look at the QCanvas code, I haven't figured out yet how it does this... perhaps simply checking if we're scrolling and skipping some of the draw operations in that case might help. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2005-07-30 17:52:24
|
On Saturday 30 Jul 2005 18:48, Guillaume Laurent wrote: > On Saturday 30 July 2005 13:09, Chris Cannam wrote: > > Also, it scrolls my big test file quite a bit slower than 1.0 (or > > rather than the STG branch, which is what I'm actually comparing > > against and I suggest you compare against as well). > > I have a 1.0 ready. Are there any differences with regard to the seg > canvas between 1.0 and STG that are worth the checkout & recompile ? I can't remember. If my descriptions seem to fit, then it's probably the same. Chris |