From the original SynthMaker forum (2004–2014), with its members’ names and dates.
mwvdlee ·
Whilst experimenting with the Midiroll thing I posted a while ago, I thought I'd try and see if a bitmap buffered would be possible and if it could help improve performance. This is an "old-skool" trick commonly used in 2D games, and it worked pretty well there.
Well... it works...
...Sadly enough though, the performance isn't all that special.
Some testing seems to indicate the actual drawing to screen buffer is what's slowing it down. Disconnect the Redraw module and everything runs at near 0% CPU (source: process explorer), even though the buffers continue to scroll internally. Apart from limiting redraws, there doesn't seem to be any way to improve performance. But perhaps somebody out there is smarter than me (quite likely, actually 😉).
I am slowly coming to the very sad conclusion that S|M simply isn't capable of updating graphics on screen quickly. It handles off-screen rendering blazingly fast, but copying a large bitmap to screen brings the system to it's knees.
aliasant ·
Interesting idea 🙂
Try replacing the knob with a Sin Osc thru a Mono to Float converter so you dont have to twist the knob.
For me, turning that knob quickly back and forth used almost 5% of my cpu.
Using an osc instead took it down to somewere between 0 and 1 but mostly 0 🙂
mwvdlee ·
aliasant wrote: Interesting idea 🙂
Try replacing the knob with a Sin Osc thru a Mono to Float converter so you dont have to twist the knob.
For me, turning that knob quickly back and forth used almost 5% of my cpu.
Using an osc instead took it down to somewere between 0 and 1 but mostly 0 🙂
Haha, the knob was just to have something user-generated rendered and scrolled.
Without decent performance, it really doesn't matter what data you display 😉
If I remove the knob completely, performance doesn't seem to change much.
I'm starting to think there may be something wrong with my graphics drivers, since other people seem to get far better performance on anything graphics related. I'm seeing average 18-20% CPU on this one.
trogluddite ·
mwvdlee wrote: I'm seeing average 18-20% CPU on this one
Feeding it with an integer random primitive divided by 33000 (to give roughly a random number from 0 to 1) gives me 1-2% CPU - like aliasant, I get 12-15% from doing it with the knob wiggles. Seems to me like your schematic is very well made indeed - a whole order of magnitude more efficient than the stock bitmap knob!. Good work, I will be poking around inside it as soon as I have the time - I think I could find a lot of uses for something like this.
FYI these CPU% are on a Q6700 Quad Core with NVIDIA GeForce 8400 graphics card - would be good for people to include more info about their machines when giving CPU figures; it's very hard to do a good comparison otherwise.
Mo ·
High cpu load in the task manager here too. Maybe the area union module can help it? [old link]
aliasant ·
mwvdlee wrote: I'm starting to think there may be something wrong with my graphics drivers, since other people seem to get far better performance on anything graphics related. I'm seeing average 18-20% CPU on this one.
Ouch.
That sounds weird indeed.
I have an i7 920 running at 3.4Ghz wit 6gb ram.
What is your machine mwvdlee?
mwvdlee ·
aliasant wrote:
mwvdlee wrote: I'm starting to think there may be something wrong with my graphics drivers, since other people seem to get far better performance on anything graphics related. I'm seeing average 18-20% CPU on this one.
Ouch.
That sounds weird indeed.
I have an i7 920 running at 3.4Ghz wit 6gb ram.
What is your machine mwvdlee?
I've got an AMD X2 4800 (dual core) with 2GB. Nonetheless, a bitmap redraw should be fast even on much older machines, especially if it's backed by hardware acceleration. I do have a VNC server running at all times, perhaps it's hooking a slow graphics driver in the driver stack. I think I should check performance on one of my other systems 🙂
mwvdlee ·
Mo wrote: High cpu load in the task manager here too. Maybe the area union module can help it? [old link]
That's effectively already what is happening; the majority of the scrolling is just copying a large part of the bitmap a little to the left, then redrawing (with clipped view) only a small strip on the right.
aliasant ·
mwvdlee wrote:
Mo wrote: High cpu load in the task manager here too. Maybe the area union module can help it? [old link]
That's effectively already what is happening; the majority of the scrolling is just copying a large part of the bitmap a little to the left, then redrawing (with clipped view) only a small strip on the right.
I didnt get any real difference when I bypassed the clip area / refresh part. Pretty much identical performance. Is that correct?
mwvdlee ·
aliasant wrote:
mwvdlee wrote:
Mo wrote: High cpu load in the task manager here too. Maybe the area union module can help it? [old link]
That's effectively already what is happening; the majority of the scrolling is just copying a large part of the bitmap a little to the left, then redrawing (with clipped view) only a small strip on the right.
I didnt get any real difference when I bypassed the clip area / refresh part. Pretty much identical performance. Is that correct?
Likely, because the thing being redrawn is very small and already fits completely inside the redraw area.
The idea is that you could redraw bigger items, moving along with the scrolling and the clipping would ensure only the new part of the image is redrawn. Clipping drawing to only a very small area should give better performance than having to redraw the entire display anew each time. This should be true even if you give draw operations for the entire display every time. The only issue is that you have to synchronize the scrolling, but that shouldn't be too hard.
sunsynth ·
Hmm,
like aliasant i get 0-0,77% CPU use with Process Explorer inside SM with an LFO instead of the knob...
'Core 2 Duo'
mwvdlee ·
sunsynth wrote: Hmm,
like aliasant i get 0-0,77% CPU use with Process Explorer inside SM with an LFO instead of the knob...
'Core 2 Duo'
I get about 15% CPU with the Multi LFO, so it's probably an issue with my particular system.
My AMD X2 4800 is a bit older than the Core2 and i7's, but not so much to make this big a difference.
Perhaps it's an OS issue? I'm working on WinXP Home with latest patches and a DirectX 9.1 GFX card.
Anyway, glad to know atleast the tricks works on other systems. That means it'd be worth extending to a practical purpose. Even though I don't know for sure it's actually needed; perhaps brute force was quick enough on normal systems.
*edit: Here's a quick hack to compensate for the ticker inaccuracy. Using green is pretty much guarenteed to be timed inaccurately, but the improvement is markedly.
Also, internally, a few things have been rewired to improve functionality in the clipped-area part.
p.s. If you set the scroll amount to non-integers, you can get a blur effect.
trogluddite ·
mwvdlee wrote: I'm working on WinXP Home
Oops, didn't put my OS in last post - I'm on XP home SP3 too, so the high CPU is not purely down to OS..
@mo - whats's your system? So far all Intel's seem good performance, and we see one slow AMD system - you are the only other to say you have high CPU - are you AMD too?
Mo ·
Last schematic uses 30 % cpu when i look under processes in task manager. In SM i see 0.7 % CPU. Using laptop XP SP3 intel core duo T2400.
Tzarls ·
I´m getting 87-95% CPU usage (task manager), but that´s on my netbook (Atom 270), so I guess this doesn´t count.
Funny how scrolling works fine on my cell phone with all those Java games. 😀
mwvdlee ·
Tzarls wrote: I´m getting 87-95% CPU usage (task manager), but that´s on my netbook (Atom 270), so I guess this doesn´t count.
Funny how scrolling works fine on my cell phone with all those Java games. 😀
It gets weirder.
On my laptop (Core2Duo @ 2500, WinXP Pro +SP3), the latest schematic also uses about 20% CPU.
Here's the weird thing; on my laptop, the following schematic maxes out on 50% (which is one full core on my dual core!)
Yes, that's right, a schematic that consists of just three basic components in a module; a GUI, a Redraw and a 25 ticker. CPU% seems to be based primarily on module GUI size.
Could you guys please post the OS you're using? GDI and GDI+ are internally vastly different on pre-XP, XP, Vista and 7 so I suspect the specific OS may have something to do with this.
aliasant ·
mwvdlee wrote: Could you guys please post the OS you're using? GDI and GDI+ are internally vastly different on pre-XP, XP, Vista and 7 so I suspect the specific OS may have something to do with this.
Hohooo. 🙂
That last osm is funny.
I get 10% cpu using Process Explorer and only looking at SM.
Edit: Tha was wit the main window in SM highlighted/selected.
If I deselect it cpu usage goes down to 0-2%
Still quite odd and I think you shold send hat to Malc.
Perfect example for him.
Same here - it uses 25% (one whole core) on my quad core too, and it takes an age for the toolbox to get loaded .
Tried the greedy schematic as exe and vst exports too - same high CPU. Resizing the module behaves very oddlly too - GUI CPU load is not simply proportional to the size of the module. I can make it fill about 1/16th o the screen with <1% CPU load. As I slowly make it bigger, I get to a point where CPU suddenly goes up to about 10%. It then carries on going up in a series of these 'jumps' until the CPU core maxes out (approx 1/3 of the screen sized module).
Then I reloaded the scroller schematic - and sure enough, if I make the scolling module about 4 grids higher, the CPU jumps from 2% to 11%. Then it stays that way until the module is about twice its original height, when CPU jumps again - to about 20%. A few grids bigger, and the core maxes out. (remember to deselect the module after resizing - having a module selected can affect the CPU reading too).
So the secret is to be careful with the module GUI sizes - but I'm damned if I can explain why the CPU load should rise in discrete jumps like that. I guess each person's system will have slightly different thresholds for the CPU lload jumps - which would explain why we're all seeing massively different results from the same schematic.
trogluddite ·
Here's a little osm I put together to show the above effect.
Resize the big empty module so that it fills as much screen as possible. Then deselect it. Open CPU monitor then flip the switch on the 'slider' module.
The slider module then slowly ramps up the area of the big module's GUI that gets redrawn (takes a couple of minutes).
On my system, I can clearly see the CPU load rising in 10% steps with nice even CPU use in between. Once the first core maxes out, all hell breaks loose as the load gets shunted around the other cores - my four CPU load graphs just start going up and down like rollercoasters!
MyCo ·
just a side note on this: You redraw a full screen with ~4000 grid lines 25 times per second with GDI+... a full core usage is normal for that.
infuzion ·
Honestly, I don't think SM was ever intended to have such huge screen redraws. Just knob animation & a very occasional full redraw for switching tabs.
mwvdlee ·
trogluddite wrote: Here's a little osm I put together to show the above effect.
Resize the big empty module so that it fills as much screen as possible. Then deselect it. Open CPU monitor then flip the switch on the 'slider' module.
The slider module then slowly ramps up the area of the big module's GUI that gets redrawn (takes a couple of minutes).
On my system, I can clearly see the CPU load rising in 10% steps with nice even CPU use in between. Once the first core maxes out, all hell breaks loose as the load gets shunted around the other cores - my four CPU load graphs just start going up and down like rollercoasters!
Behaviour of this is just almost random.
Switching the switch doesn't always affect CPU%, in fact I can find no descernable pattern.
Sometimes I switch it off and CPU remains at 20%, sometimes I can switch it on and CPU stays near 0%, slowly building up to 20% (sometimes takes well over a minute to get there).
However, CPU% seems to change more dramatically after I both change the switch AND minimize/maximize the window.
This is some very strange behaviour indeed.
mwvdlee ·
MyCo wrote: just a side note on this: You redraw a full screen with ~4000 grid lines 25 times per second with GDI+... a full core usage is normal for that.
That doesn't explain why some people keep seeing 0% and other need a full core for it.
aliasant ·
trogluddite wrote: Here's a little osm I put together to show the above effect.
Resize the big empty module so that it fills as much screen as possible. Then deselect it. Open CPU monitor then flip the switch on the 'slider' module.
The slider module then slowly ramps up the area of the big module's GUI that gets redrawn (takes a couple of minutes).
On my system, I can clearly see the CPU load rising in 10% steps with nice even CPU use in between. Once the first core maxes out, all hell breaks loose as the load gets shunted around the other cores - my four CPU load graphs just start going up and down like rollercoasters!
Hmm.
I maxed out at 10% after about 5 minutes and that was with the window highlighted.
If I deselect the window its about 5%.
Using VLC and watching a full screen movie is using about 5% so to me that seems to be what redrawing the entire screen 25/sec should take.
That is true if I deselect the window or use it as a VST or .exe.
Not sure why it uses so much more when a window is highlighted in SM but theres probably a good reason.
I use that "phenomena" as an indicator that I havnt optimized redrawings as well as I could so it serves a purpose for me, sort of.
I have also noticed that size matters.. It seems to redraw the screen in "chunks".
When using larger images that moves, say from left to right I can sometimes see that the upper part of the image is moved slightly before the lower part so the result looks pretty bad. When the image stops moving it looks fine again.
The only solution when that happens is to resize it small enough so that everything is drawn in 1 chunk. Not ideal.
I had a discussion with Malc about that last year and I think he said something like, "that is how windows works" and thats probably true. If we could get some basic hardware accelerated redraws that would help a lot. Doesnt have to be full 3D support or anything. Just have the graphic card do the graphics... as its supposed to.
mwvdlee ·
aliasant wrote: I had a discussion with Malc about that last year and I think he said something like, "that is how windows works" and thats probably true. If we could get some basic hardware accelerated redraws that would help a lot. Doesnt have to be full 3D support or anything. Just have the graphic card do the graphics... as its supposed to.
Ideally, you'd sync graphics redraw with the actual screen refresh, and even then you can get flickering unless you either time everything perfectly or use hardware double buffering techniques. AFAIK, GDI/GDI+ cannot do any of this, you'd need DirectX to handle that.
The implementation of GDI depends on the version of windows.
XP; GDI hardware accellerated, GDI+ could be hardware accellerated but almost never is.
Vista; Neither is hardware accellerated.
7; Both are typically hardware accellerated by layering GDI/GDI+ over the new WDDM system, which is accellerated by default.
Microsoft really messed up GDI support.
<offtopic rant>
WDDM should be the replacement, but it only works on Vista or 7. GDI will probably be with us for atleast a decade more (and probably a century after that) if only because of all the legacy code that depends on it (much of which was badly wounded by Vista). Luckily they wisened up and retrofitted hardware accelleration of GDI in 7; they could and should have done this with Vista.
</offtopic rant>
Andrew J ·
I remember reading somewhere that the latest video cards were actually going backwards with respect to GDI performance. Tom's Hardware Guide I think.
Interestingly, there's been some posts about how much faster lice is than GDI over on the Cockos WDL forum. I imagine it would be a large amount of work for Outsim to move away from GDI though....
mwvdlee ·
Andrew J wrote: Interestingly, there's been some posts about how much faster lice is than GDI over on the Cockos WDL forum. I imagine it would be a large amount of work for Outsim to move away from GDI though....
...and it would mean breaking compatibility with XP. I imagine not many people being too happy about that one, including me 🙂
Andrew J ·
You lost me there - why would it break compatibility with XP? There's plenty of non GDI graphics solutions in use on XP - lice is one of them in fact. Try out the test app in the top post of http://forum.cockos.com/showthread.php?t=59714 to compare performance on your system.
MyCo ·
As soon as you use a graphic buffer (and Malc said that S|M does), Lice loses against GDI+. Also there are things that you can't do with Lice, eg. hittesting with something like IsOutlineVisible. Also the performance test from the link is a little bit unfair, because GDI+ is running with the highest Anti-Aliasing and Alpha-Blending settings. 😉
infuzion ·
Andrew J wrote: I remember reading somewhere that the latest video cards were actually going backwards with respect to GDI performance. Tom's Hardware Guide I think.
Yes, but it is more of an driver issue. Very few people time the FPS of their desktop, so most manpower goes to faster 3d.
Andrew J ·
infuzion wrote:
Andrew J wrote: I remember reading somewhere that the latest video cards were actually going backwards with respect to GDI performance. Tom's Hardware Guide I think.
Yes, but it is more of an driver issue. Very few people time the FPS of their desktop, so most manpower goes to faster 3d.
Exactly - though I think AMD did do a bit of work on the Catalyst drivers so that things weren't quite so dire.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker