Glitch with long TCO's

[zonkmachine]

The end of the SampleTCOView of long Sample Tracks sometimes gets distorted.
I've only seen this occasionally with really long samples, 30+ minutes, so far.

[zonkmachine]

3.5 minute into a 5 minute .ogg sample

[BaraMGB]

Have you noticed this only in ogg files?

[zonkmachine]

Have you noticed this only in ogg files?

It's in wav files too. Found the commit.

@Umcaruje

commit f136ba3097d45b8651e45b494f8af5a6d606cd59
Author: Umcaruje <uros.maravic@gmail.com>
Date:   Tue Feb 16 01:01:43 2016 +0100

    Refactor the drawing of TCO's; Get rid of hardcoded colors in TCOs; Make TCO gradient configurable; Even out the color scheme
    Thanks to @Fastigium for helping with the BB Pattern redraw problem

[Umcaruje]

Huh, looks like something is not getting initialised. You can get these glitches on all patterns if you remove the style.css. I'll look into this.

[Umcaruje]

I'm sorry, I can't reproduce this. I loaded a 30 minute ogg and it seems to render fine 😕

[zonkmachine]

Sometimes you need to also zoom in to trigger this.

[Umcaruje]

@zonkmachine could you zip up a file that does this?

[Umcaruje]

Also are you on Qt4 or Qt5?

[zonkmachine]

Qt4, Linux Mint 17.3 with cheap AMD cpu and no dedicated graphic card.

[zonkmachine]

@zonkmachine could you zip up a file that does this?

Aight!
sampleend.zip
This one is buggy on 1600% zoom from bar 129.

[zonkmachine]

If I scroll the tempo the glitch is affected.

[Umcaruje]

Ok I can reproduce now, thanks.

[Umcaruje]

This is not a problem with sample TCO's, but with all TCO's:

The reason this was introduced with my commit is because I switched all TCO's to draw to a m_paintPixmap to not have excessive redrawing, and to keep consistency with all other TCO's.

As you see the problem exists in 1.1.3 with patterns using this method.

Investigation ahead...

[Umcaruje]

Seems like a QPixmap can't be more than 32767 x 32767px in size...

[musikBear]

This could have bearings to #746
If 30 mins is a maximum, then 746 could force a mandatory split of a block when it is 29 mins long.

[PhysSong]

Seems like a QPixmap can't be more than 32767 x 32767px in size...

Can we use multiple QPixmap instances for long TCOs? If it's possible, we can be free from the pixel limit.

[zonkmachine]

Or borrow space from the vertical part of the pixmap. Just continue writing the pixmap but roll back to 0, let it grow in size vertically and continue writing/reading.

[Spekular]

Wouldn't that vertical solution cause problems with resizing tracks vertically? Unless I'm missing something, we must draw a taller pixmap (height tied to track height) to retain sharp graphics when that happens.

…

On Wed, Sep 18, 2019, 22:09 Oskar Wallgren ***@***.***> wrote: Or borrow space from the vertical part of the pixmap. Just continue writing the pixmap but roll back to 0, let it grow in size vertically and continue writing/reading. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3378?email_source=notifications&email_token=ACEBLGTAVT25GVOL7CNIAADQKKDIZA5CNFSM4DBBEMW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7BJL5Q#issuecomment-532846070>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACEBLGVICS2UWZR562QXRA3QKKDIZANCNFSM4DBBEMWQ> .

[michaelgregorius]

The current implementation seems to be quite inefficient with regards to memory performance. I have added some debug code to the implementation of resizeEvent in Track.h. The added code simply captures the new size of the widget.

If I open the project contained in the file sampleend.zip (see original attachment above), extend the height of the sample track to a nice height for my screen and zoom in to 1600% then the size of the widget (and the associated QPixmap) becomes 40871x103 = 4209713 pixels. Assuming four bytes per pixel (RGBA) the associated pixmap uses around 16 MB for only one track. And most of it is not even visible on the screen. If a project has several long tracks then this becomes quite wasteful.

A potential fix might be to make the tracks aware of the zoom level and the area that needs a redraw and to only redraw that area on the fly without any caching.