slow waveform draw in sample editor

Started by aleksb, January 28, 2014, 12:56:45

Previous topic - Next topic

aleksb

hello all

in the sample editor of the latest openMPT the waveform of a sample gets drawn out very slowly, rendering mpt unresponsive while it's being drawn, sometimes for a couple of seconds (i didn't use to have this problem before).

would you know how to get around this?

thank you!

Saga Musix

Which version are you referring to? The latest stable or testing? In the current testing versions, waveform drawing is all done in a backbuffer to prevent update artefacts when desktop compositing is enabled. While the sample is being drawn to the backbuffer, no GUI updates will happen so yes, it will look like OpenMPT doesn't do anything. However, if anything, it should make the whole process faster rather than slower, so OpenMPT shouldn't be as unresponsive as it used to be.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

aleksb

thank you for the reply.

it's version 1 22 07 00 (the one my old MPT asked me to update to automatically).

i was going to make a vid of the redraw issue but strangely (or logically?) camtasia does actually not capture that when recording video realtime.

aleksb


Saga Musix

Eh, there is no reason in our code why it should look/update like that, and I can't think of any reason why it would be *that* slow. Are you maybe on a slow netbook, or don't have the latest graphics driver installed, or something like that? Also, do the old versions definitely not expose the problem? Please also try the latest test version just to confirm that we're not hunting old bugs that are gone with the slightly modified waveform display.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

aleksb

Quote from: Saga Musix on January 28, 2014, 20:28:54
Eh, there is no reason in our code why it should look/update like that, and I can't think of any reason why it would be *that* slow. Are you maybe on a slow netbook, or don't have the latest graphics driver installed, or something like that? Also, do the old versions definitely not expose the problem? Please also try the latest test version just to confirm that we're not hunting old bugs that are gone with the slightly modified waveform display.

not sure what the culprit could be.. it's a q9550 machine (this is on a 2560x1440 display, and there's a secondary display connected as well; the GPU is some most basic ATI card. it has the latest drivers installed).

i shall try the version you submitted.

i haven't had a chance to test a previous version as i've overwritten my only version with the latest update.

LPChip

Also just to test things, if you go to your windows power management settings, by default its set to balanced and laptops may set it to economic even. Can you select high performance and test it? Strangely enough, high performance can make weird speed problems vanish in thin air when you are on balanced.
"Heh, maybe I should've joined the compo only because it would've meant I wouldn't have had to worry about a damn EQ or compressor for a change. " - Atlantis
"yes.. I think in this case it was wishful thinking: MPT is makng my life hard so it must be wrong" - Rewbs

aleksb

Quote from: LPChip on January 28, 2014, 20:35:46
Also just to test things, if you go to your windows power management settings, by default its set to balanced and laptops may set it to economic even. Can you select high performance and test it? Strangely enough, high performance can make weird speed problems vanish in thin air when you are on balanced.

sorry i haven't been clear. it's a desktop system.

the possibly relevant specs are as follows:
--core2quad q9550
--win 7 x64
--12GB RAM
--2x 27" LCDs
--RME interface
--(one of the cheapest) ATI radeon card

Re: power settings: I've got things set, as is usually recommended for audio, to prioritize background services.

MPT is so lightweight though and i don't use any VSTs in it that this shouldn't matter either way I am guessing.


aleksb

Quote from: aleksb on January 28, 2014, 20:34:35
Quote from: Saga Musix on January 28, 2014, 20:28:54
Eh, there is no reason in our code why it should look/update like that, and I can't think of any reason why it would be *that* slow. Are you maybe on a slow netbook, or don't have the latest graphics driver installed, or something like that? Also, do the old versions definitely not expose the problem? Please also try the latest test version just to confirm that we're not hunting old bugs that are gone with the slightly modified waveform display.

not sure what the culprit could be.. it's a q9550 machine (this is on a 2560x1440 display, and there's a secondary display connected as well; the GPU is some most basic ATI card. it has the latest drivers installed).

i shall try the version you submitted.

i haven't had a chance to test a previous version as i've overwritten my only version with the latest update.

this version seems working as expected, thank you!

Saga Musix

Good to see that the new code fixes two problems at the same time then. :)
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

aleksb

thank you.

just made a small donation to mpt.