Timeline drawing bug when add instrument dialog gets closed.

[John Kelly]

There appears to be a problem with the cached image of the timeline in jokosher. The problem is that the add instrument dialog window border appears in the timeline when the add instrument dialog is closed.
http://www.filehigh.com/serve/12691/268205.png

There are two work arounds for this bug. Change the position of the add instrument dialog so that it doesnt appear over the timeline or add the line self.project.RedrawTimeLine = True in the add instrument dialog class constructor. The second solution doesnt really fix the problem as it has to redraw the image and then store it in memory which is slower than just fetching the cached image. Something is happening to the cached image.

[Jean-Francois Arseneau (jf-arseneau)]

This bug did occur with GEdit being sort of imprinted in the timeline, so this is not unique to the Add Instrument dialog. However, I can't figure out a way to reliably reproduce this.

[John Green (john-thegreens)]

I have Jokosher running on two machines here; one dappy, the other edgy. I have seen this happen occassionally on the dapper box which I use less frequently. On the edgy box I've never seen it. People have commented that the cached image is getting corrupted. It isn't. If you toggle to mix view and back again you are reading the cached image and the corrupt drawing area disappears. Also normally when a window closes if the window underneath is not redrawing the area then that area is just blank. You don't get bits of title bar from the covering window left. I think this has to be window manager or possibly video driver related though why it only happens to the timeline is a bit of a mystery. Moving the instrument dialog down will hide the problem although it will ruin the symmetry we now have with all the dialogs nicely centered.

[Laszlo Pandy (laszlok)]

<quote>
    ...though why it only happens to the timeline is a bit of a mystery.
</quote>

Its not really a mystery. It happens only on this widget because this is the only custom widget we have that doesn't use cairo. For 0.9 the timeline will be rewritten to use cairo (cause it has some other problems too), and that will hopefully solve it once and for all.

I suggest we put in the workaround for 0.2 though.

[John Green (john-thegreens)]

Workaround committed in r929.

The status is now fudged for 0.2 and moved to 0.9

[baze (bjoern-martensen)]

this problem still exists in the current head and also in other cases, for example when you have another window overlapping the timeline and change the gtk theme.

[David Corrales (davidcorrales)]

I'm working on a Cairo solution to this issue.

[baze (bjoern-martensen)]

seems to work and it looks better than before too :)
just a question though: would it be possible to redraw the red and blue index lines (red while playback, blue for the cursor position) using cairo too?
i think the slightly thicker line looks nice and the red line sometimes doesn't exactly sync with its parts in the field with the wave form and the tiny grey space below that field.
the index lines should all match in width.

i had some redraw errors with the other blue line (opened the context menu, didn't move the mouse, close it by left clicking -> top of the blue line which was not covered by the menu was still drawn, the lower part was not), but that seems to be gone, nice :)

[Laszlo Pandy (laszlok)]

>just a question though: would it be possible to redraw the red and blue index lines (red >while playback, blue for the cursor position) using cairo too?

These have been drawn using cairo since forever. I'm pretty sure the thicknesses area all the same.

[baze (bjoern-martensen)]

nope, the red line is 1px while the time line index is 2px. 2 px for both would be better, imho.