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
All 19 comments
3.5 minute into a 5 minute .ogg sample
zonkmachine
on 22 Feb 2017
Have you noticed this only in ogg files?
BaraMGB
on 22 Feb 2017
Have you noticed this only in ogg files?
It's in wav files too. Found the commit.
@Umcaruje
commit f136ba3097d45b8651e45b494f8af5a6d606cd59
Author: Umcaruje <[email protected]>
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
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
on 22 Feb 2017
I'm sorry, I can't reproduce this. I loaded a 30 minute ogg and it seems to render fine :confused:
Umcaruje
on 22 Feb 2017
Sometimes you need to also zoom in to trigger this.
zonkmachine
on 22 Feb 2017
@zonkmachine could you zip up a file that does this?
Umcaruje
on 22 Feb 2017
Also are you on Qt4 or Qt5?
Umcaruje
on 22 Feb 2017
Qt4, Linux Mint 17.3 with cheap AMD cpu and no dedicated graphic card.
zonkmachine
on 22 Feb 2017
@zonkmachine could you zip up a file that does this?
Aight!
sampleend.zip
This one is buggy on 1600% zoom from bar 129.
zonkmachine
on 22 Feb 2017
If I scroll the tempo the glitch is affected.
zonkmachine
on 22 Feb 2017
Ok I can reproduce now, thanks.
Umcaruje
on 23 Feb 2017
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
on 23 Feb 2017
Seems like a QPixmap can't be more than 32767 x 32767px in size...
Umcaruje
on 23 Feb 2017
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.
musikBear
on 24 Feb 2017
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.
PhysSong
on 31 Jul 2019
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.
zonkmachine
on 18 Sep 2019
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 notifications@github.com 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
https://github.com/LMMS/lmms/issues/3378?email_source=notifications&email_token=ACEBLGTAVT25GVOL7CNIAADQKKDIZA5CNFSM4DBBEMW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7BJL5Q#issuecomment-532846070,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACEBLGVICS2UWZR562QXRA3QKKDIZANCNFSM4DBBEMWQ
.
Spekular
on 19 Sep 2019
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.
michaelgregorius
on 20 Sep 2019
Related issues
mikobuntu
·
4Comments
Sawuare
·
3Comments
demmm
·
3Comments
SecondFlight
·
3Comments
TrumpislikeCyrus
·
4Comments
Most helpful comment
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 notifications@github.com wrote: