From: Chris C. <ca...@al...> - 2002-05-29 19:23:47
|
I've just checked in some code for doing previews of Internal segments on the segment canvas (i.e. drawing a little line in the segment item for each note in the segment). I'm not claiming that it does them sensibly, but I was tired of having no kind of preview at all so I thought I should at least start an argument about them. Hence, let me know what you think. The main problem I have is not design but efficiency: it's very, very slow. I suspect what's happening is that it's being asked to redraw the whole thing each time a refresh happens, rather than being able to selectively repaint only parts of the segment, which is what I hoped the code I wrote would do. (i.e. it draws only the area of rect(), but I guess rect() is larger than I'd hoped. Guillaume?) This is presumably also a problem for audio previews. Also it doesn't get a refresh when the segment changes (because that's never been necessary before), and the preview interferes somewhat with the label. Even if we fix these things, I imagine it'll be desirable to be able to switch previews off if things are slowing down a bit. And of course I'm sure I don't have the best display format; at this resolution I'm not sure it's worth showing pitch at all, for instance: it might be better just to have a slightly taller vertical bar or block at a fixed height. Or even empty rectangles that extend for the whole of a period during which there may be many notes, ending only when a significant-size rest is encountered. Chris |
From: Chris C. <ca...@al...> - 2002-05-29 21:49:14
|
Chris Cannam wrote: > The main problem I have is not design but efficiency: it's very, > very slow. I suspect what's happening is that it's being asked > to redraw the whole thing each time a refresh happens Oh boy -- and if you play the piece, it redraws every time the position pointer moves. That really, really fucks playback. Chris |
From: Chris C. <ca...@al...> - 2002-05-30 18:59:23
|
Chris Cannam wrote: > empty > rectangles that extend for the whole of a period during which > there may be many notes, ending only when a significant-size > rest is encountered I've checked in this style as well, with an #ifdef (of which it's the default). I think I possibly prefer it. There's a bug meaning if only one "period during which there may be many notes" exists on a segment, the rectangle doesn't appear, but that's a trivial problem beside the fact that although it's quicker than the other preview method it still makes the whole thing unusably slow, especially on playback. Chris |
From: Chris C. <ca...@al...> - 2002-06-05 08:24:26
|
KDE2/Qt2: segmentcanvas.cpp: In method `void SegmentItem::drawShape (QPainter &)': segmentcanvas.cpp:161: `CoordPainter' is not a member of type `QPainter' So even my attempt to handle updates when clipping _is_ enabled ends in failure. Well, I guess whatever technique we end up finding for getting hold of the repaint coordinates when clipping isn't enabled will probably also work when it is. I should probably stick to the Qt 2 API documentation in future. Chris |
From: Chris C. <ca...@al...> - 2002-06-01 07:44:58
|
Very mysterious. I've just modified SegmentItem::drawShape to work on the assumption that the QPainter passed to it already has a valid clipping rectangle outside of which it makes no sense to paint, and that we can speed up the repaint by only calculating previews for this rectangle. Unfortunately it doesn't appear to be true -- the rectangle generally has its origin at (0,0) for each repaint during playback -- see the debug output I've added. Any idea why this would be? Chris |
From: Chris C. <ca...@al...> - 2002-06-01 08:04:05
|
Chris Cannam wrote: > Any idea why this would be? Oh, I get it -- the coord mode was local to the painter. Works now, although there are some interesting difficulties with selecting the correct events to preview for a given region. Chris |
From: Guillaume L. <gla...@te...> - 2002-06-01 08:52:17
|
On Saturday 01 June 2002 10:01, Chris Cannam wrote: > > Oh, I get it -- the coord mode was local to the painter. Yes, it always is. Sorry for arriving after the battle. > Works now, although there are some interesting difficulties > with selecting the correct events to preview for a given > region. It doesn't seem to scroll well, though. BTW, is the chord name ruler disabled ? It doesn't show anything anymore. Damn, I managed to trigger a crash in ~NotationView (removeViewLocalProperties() is called with a null event), but I can't reproduce it. Try opening a testfile, disable/enable the chord name ruler, then close the notation window. Strange. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-06-01 10:44:40
|
Guillaume Laurent wrote: > It doesn't seem to scroll well, though. No, it doesn't do the right thing when the painter is unclipped yet. > BTW, is the chord name ruler disabled ? It doesn't show anything anymore. It seems to work for me, in, say, glazunov.rg. There is a problem there though -- the loop rulers are missing, probably through a side-effect of my attempt to fix the problem with squished-up chord names on the chord name ruler. > Damn, I managed to trigger a crash in ~NotationView > (removeViewLocalProperties() is called with a null event), but I can't > reproduce it. Try opening a testfile, disable/enable the chord name ruler, > then close the notation window. Strange. Haven't managed to reproduce this -- let me know if you do. Chris |
From: Richard B. <bo...@bo...> - 2002-06-01 11:04:27
|
Sorry, I have nothing else further to add at this time. I know that I'm kind of the lone football supporter on the RG development team at the moment but I still like seeing the world champions getting humiliated. Of course we only have to wait twenty four hours for England's first humiliation to the pitch too I s'pose.. B |
From: Guillaume L. <gla...@te...> - 2002-06-01 13:59:56
|
On Saturday 01 June 2002 13:15, Richard Bown wrote: > Sorry, I have nothing else further to add at this time. Can't blame you. Many of my friends and colleagues had a chuckle about this too :-). -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-06-01 12:36:24
|
Chris Cannam wrote: > Guillaume Laurent wrote: > >>It doesn't seem to scroll well, though. > > No, it doesn't do the right thing when the painter is > unclipped yet. I see we can get the viewport dimensions when the painter is unclipped by calling viewport() on it, but I don't see how to get the origin for the repaint. (See the output -- the origin is always 0,0 again for unclipped paints.) Any idea? Chris |
From: Guillaume L. <gla...@te...> - 2002-06-01 18:34:07
|
On Saturday 01 June 2002 12:41, Chris Cannam wrote: > > Damn, I managed to trigger a crash in ~NotationView > > (removeViewLocalProperties() is called with a null event), but I can't > > reproduce it. Try opening a testfile, disable/enable the chord name > > ruler, then close the notation window. Strange. > > Haven't managed to reproduce this -- let me know if you do. Got it. Just quit with a Notation window open. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-06-01 21:30:33
|
Guillaume Laurent wrote: > Just quit with a Notation window open. Strange. Yes, that does appear to crash it (some of the time). But I can't see why -- I'd have guessed it was that the document was being destroyed before the notation view, but I haven't found the evidence yet. btw, it's damn difficult to enter notes longer than a crotchet in the matrix view these days. I've been trying to track down the cause of the occasional failure to find HEIGHT_ON_STAFF properties in NotationVLayout after notes were added in the matrix with a notation view open, but it's so hard to even add the notes... Chris |
From: Guillaume L. <gla...@te...> - 2002-06-01 17:13:43
|
On Saturday 01 June 2002 14:33, Chris Cannam wrote: > > Guillaume Laurent wrote: > >>It doesn't seem to scroll well, though. > > > > No, it doesn't do the right thing when the painter is > > unclipped yet. This quite reminds me of the scrolling problems we had with the time rulers ticks. > I see we can get the viewport dimensions when the painter > is unclipped by calling viewport() on it, but I don't see > how to get the origin for the repaint. (See the output -- > the origin is always 0,0 again for unclipped paints.) > > Any idea? QPainter::window() perhaps ? -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-06-01 17:47:46
|
Guillaume Laurent wrote: > On Saturday 01 June 2002 14:33, Chris Cannam wrote: >>I see we can get the viewport dimensions when the painter >>is unclipped by calling viewport() on it, but I don't see >>how to get the origin for the repaint. (See the output -- >>the origin is always 0,0 again for unclipped paints.) > > QPainter::window() perhaps ? Nah, that returns the same as viewport(). I'm beginning to think I may have to make the SegmentItem keep a pointer to its SegmentCanvas and query the scrolled origin from that. At least that would simplify the odd other thing a bit too (like it could query show-preview status from the canvas instead of having to store it, and likewise for the snap grid etc -- thus using less memory and fewer of these update-every-segment-item loops in the canvas code). btw I notice we never got around to making the repeat rectangles paint themselves when necessary either -- now that repeat is a command (isn't it?) this and the problem of updating previews when the notes change are probably pretty much the same problem. Chris |
From: Guillaume L. <gla...@te...> - 2002-06-01 17:20:41
|
On Saturday 01 June 2002 12:41, Chris Cannam wrote: > > > BTW, is the chord name ruler disabled ? It doesn't show anything anymore. > > It seems to work for me, in, say, glazunov.rg. Oh yes, except that scrolling is broken for these too (when I scroll to the right, labels suddenly disappear). I suppose the testfile I was trying with had no distinctive chords to extract. > problem there though -- the loop rulers are missing, probably > through a side-effect of my attempt to fix the problem with > squished-up chord names on the chord name ruler. I still have them, and they're working... -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-06-01 17:48:34
|
Guillaume Laurent wrote: > scrolling is broken for these too (when I scroll to the > right, labels suddenly disappear). I suppose the testfile I was trying with > had no distinctive chords to extract. > [...] > I still have [loop rulers], and they're working... I restored the loop rulers and the old-broken chord ruler behaviour after I sent that email, so you may have that version. "When I scroll to the right, labels suddenly disappear" -- are you sure you aren't getting too many labels until you scroll, and then the correct number and spacing only when you scroll? The right behaviour should be obvious for something like glazunov, but for a lot of files it won't generate very many labels at all. I've just checked in another hack at it which appears to do everything correctly for me -- the labels and loop rulers are there and scroll okay. Try it out. btw, I also added a Show Segment Previews toggle to the Settings menu, but I can't work out how to get it to repaint the canvas correctly when the setting changes. Chris |
From: Guillaume L. <gla...@te...> - 2002-06-01 18:24:53
|
On Saturday 01 June 2002 19:45, Chris Cannam wrote: > > I restored the loop rulers and the old-broken chord ruler > behaviour after I sent that email, so you may have that > version. Probably. > "When I scroll to the right, labels suddenly > disappear" -- are you sure you aren't getting too many > labels until you scroll, and then the correct number and > spacing only when you scroll? Yes. The chord labels are at the right places, but they completely vanish all of a sudden if I scroll right a little. > I've just checked in another hack at it which appears to > do everything correctly for me -- the labels and loop > rulers are there and scroll okay. Try it out. OK, will do and report here. > btw, I also added a Show Segment Previews toggle to the > Settings menu, but I can't work out how to get it to > repaint the canvas correctly when the setting changes. What's the problem exactly ? The method to call should be SegmentCanvas::slotUpdate(). Better emit a signal than calling it directly. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2002-06-01 18:14:49
|
On Saturday 01 June 2002 19:44, Chris Cannam wrote: > > I'm beginning to think I may have to make the SegmentItem > keep a pointer to its SegmentCanvas and query the scrolled > origin from that. Hold on. We really shouldn't have to do this, so my guess is that we're looking at things the wrong way or trying to do something stupid. > At least that would simplify the odd > other thing a bit too (like it could query show-preview > status from the canvas instead of having to store it, and > likewise for the snap grid etc -- thus using less memory > and fewer of these update-every-segment-item loops in the > canvas code). You totally lost me there. Can you explain this a little ? > btw I notice we never got around to making the repeat > rectangles paint themselves when necessary either -- now > that repeat is a command (isn't it?) this and the problem > of updating previews when the notes change are probably > pretty much the same problem. Yes. Given the speed problem I think we'll need to cache the "preview" info somewhere and find a way to update it as needed. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-06-01 20:20:07
|
Guillaume Laurent wrote: > On Saturday 01 June 2002 19:44, Chris Cannam wrote: > >>I'm beginning to think I may have to make the SegmentItem >>keep a pointer to its SegmentCanvas and query the scrolled >>origin from that. > > Hold on. We really shouldn't have to do this, so my guess is that we're > looking at things the wrong way or trying to do something stupid. Well, the only thing that suggests we _have_ to do this is that I haven't managed to work out how to get the viewport origin given only the SegmentItem and the QPainter -- if you can work out how to do that, that'll be fine. >> At least that would simplify the odd >>other thing a bit too (like it could query show-preview >>status from the canvas instead of having to store it, and >>likewise for the snap grid etc -- thus using less memory >>and fewer of these update-every-segment-item loops in the >>canvas code). > > You totally lost me there. Can you explain this a little ? Forget the snap grid thing -- I've realised the segment item just keeps a pointer to that. As for the show-preview status, well, each time we want to change that from the GUI we call a method on SegmentCanvas which then trawls through all its Items telling each one individually that the preview status has changed. If the Item had a pointer to the SegmentCanvas (or even just a pointer to the boolean status setting, but that's no nicer) then it could just query the current status on each refresh instead of having to store it and be updated explicitly. (This is very obvious stuff, I'm just rather tired today and not having much luck with my writing skills.) >>btw I notice we never got around to making the repeat >>rectangles paint themselves when necessary either -- now >>that repeat is a command (isn't it?) this and the problem >>of updating previews when the notes change are probably >>pretty much the same problem. > > Yes. Given the speed problem I think we'll need to cache the "preview" info > somewhere and find a way to update it as needed. Now you hold on. Let's worry about optimisations later; for the moment all I want to do is make sure we get an appropriate repaint call when something changes in a segment that means the preview needs updating, or when a segment's repeat status changes. At the moment neither of these things happens, you need to do something else (such as scroll the view) to tell the canvas that it needs to update the segment items. [other email:] >> I also added a Show Segment Previews toggle to the >> Settings menu, but I can't work out how to get it to >> repaint the canvas correctly when the setting changes. > > What's the problem exactly ? The method to call should be > SegmentCanvas::slotUpdate(). Better emit a signal than calling it > directly. Yes, I'm calling it from SegmentCanvas::setShowPreviews, but it doesn't appear to work. Perhaps the QCanvas is clever enough to realise that the rectangle hasn't actually moved or anything and so shouldn't need to be redrawn? Chris |
From: Guillaume L. <gla...@te...> - 2002-06-02 14:20:09
|
On Saturday 01 June 2002 22:17, Chris Cannam wrote: > > Well, the only thing that suggests we _have_ to do this is > that I haven't managed to work out how to get the viewport > origin given only the SegmentItem and the QPainter -- if you > can work out how to do that, that'll be fine. OK, but if I understood correctly, you need that because when scrolling, the clipping rectangle is empty, right ? But I'd really like to understand why this is the case, and how other canvas items handle this. > As for the show-preview status, well, each time we want to > change that from the GUI we call a method on SegmentCanvas > which then trawls through all its Items telling each one > individually that the preview status has changed. If the > Item had a pointer to the SegmentCanvas (or even just a > pointer to the boolean status setting, but that's no nicer) > then it could just query the current status on each refresh > instead of having to store it and be updated explicitly. OK, I think I understand. > a segment's repeat status changes. At the moment neither of > these things happens, you need to do something else (such as > scroll the view) to tell the canvas that it needs to update > the segment items. Yes. I'm currently finishing switching Configuration over to PropertyMap. I'll join you on this as soon as I'm done. > Yes, I'm calling it from SegmentCanvas::setShowPreviews, but > it doesn't appear to work. Perhaps the QCanvas is clever > enough to realise that the rectangle hasn't actually moved > or anything and so shouldn't need to be redrawn? Perhaps QCanvas::setChanged ( const QRect & area ) is your friend. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-06-02 14:34:20
|
Guillaume Laurent wrote: > On Saturday 01 June 2002 22:17, Chris Cannam wrote: > >>I haven't managed to work out how to get the viewport >>origin given only the SegmentItem and the QPainter > > OK, but if I understood correctly, you need that because when scrolling, the > clipping rectangle is empty, right ? But I'd really like to understand why > this is the case, and how other canvas items handle this. The clipping rectangle is empty, but also the QPainter has hasClipping() false, so I imagine the instruction is just for the rectangle to redraw itself in entirety. Possibly the canvas is making the assumption that redrawing rectangles is fast, which of course is normally true. > Perhaps > > QCanvas::setChanged ( const QRect & area ) > > is your friend. Ah yes, it is. Thanks. Chris |
From: Chris C. <ca...@al...> - 2002-06-12 19:23:40
|
I think I've worked out how to get the right clipping rectangle for drawing segment previews. (Use the worldMatrix's dx/dy coordinates to offset the painter's clip rectangle.) I still haven't quite the CPU power to ensure high-quality playback while segment previews are on, but the situation is better. Chris |
From: Richard B. <bo...@bo...> - 2002-06-13 05:42:16
|
Chris Cannam wrote: > I think I've worked out how to get the right clipping rectangle > for drawing segment previews. Does this explain why the audio previews are suddenly all over the shop? I know they weren't brilliant before but now they're not actually on their Segments anymore. B |
From: Chris C. <ca...@al...> - 2002-06-13 08:03:52
|
Richard Bown wrote: > Chris Cannam wrote: > >>I think I've worked out how to get the right clipping rectangle >>for drawing segment previews. > > Does this explain why the audio previews are suddenly all over > the shop? Possibly -- I'll get my audio path thing sorted and take a look. Previously audio previews suffered from the same problem as non- audio ones of re-rendering the whole thing whether it was needed or not, so this change will certainly have affected them. Chris |