Don Moir
You see lots of complaints about high CPU usage and over heating. For me, machine shut down several times due to overheating when running VDJ8.
I take it you already know this, but drawing the entire skin at some frames per second is crazy. Especially if using GDI or worst GdiPlus if that's the case. This is my assumption and accounts for the high CPU usage and heat for me anyway. I ended up reducing the maxSkinFPS to around 5 just so I don't have to boot back up. This is silly though since then you have a choppy UI update.
It's a VDJ issue that a sane person would fix. This is on my dev machine which is slower and I like it that way. Keeps me in touch with reality. I don't have any other program on my machine that will eat the CPU when sitting idle. Come on guys.
I take it you already know this, but drawing the entire skin at some frames per second is crazy. Especially if using GDI or worst GdiPlus if that's the case. This is my assumption and accounts for the high CPU usage and heat for me anyway. I ended up reducing the maxSkinFPS to around 5 just so I don't have to boot back up. This is silly though since then you have a choppy UI update.
It's a VDJ issue that a sane person would fix. This is on my dev machine which is slower and I like it that way. Keeps me in touch with reality. I don't have any other program on my machine that will eat the CPU when sitting idle. Come on guys.
Posted Sun 08 Jun 14 @ 2:35 am
hbessems
Seconded.
Situation: VDJ open, no tracks loaded, just full screen and open. CPU: Core 2 Duo T7250, Windows 7 64-bit, 4 GB RAM, SSD (Dell XPS M1330), 1 Hercules MP3 E2 controller connected
VDJ 7 with VDJ 7 4 deck skin: around 10% of my CPU, fluctuates between about 5 and 14
VDJ 8 with VDJ 8 4 deck skin (30 fps): 45%, spread across both cores
VDJ 8 with VDJ 7 4 deck skin (30 fps): 17-19% - still more than VDJ 7
If I reduce the skin redraw to 5 fps it is around 10% again, but I think this is unacceptably choppy. I like the new skin engine and feel, but I'd also like to be able to use my laptop in a radio studio without the fan at maximum RPM.
Given the dilemma, for now I'll stay at VDJ 7.4, which is fluid and responsive at only 10% CPU. Some optimisation may be called for.
Situation: VDJ open, no tracks loaded, just full screen and open. CPU: Core 2 Duo T7250, Windows 7 64-bit, 4 GB RAM, SSD (Dell XPS M1330), 1 Hercules MP3 E2 controller connected
VDJ 7 with VDJ 7 4 deck skin: around 10% of my CPU, fluctuates between about 5 and 14
VDJ 8 with VDJ 8 4 deck skin (30 fps): 45%, spread across both cores
VDJ 8 with VDJ 7 4 deck skin (30 fps): 17-19% - still more than VDJ 7
If I reduce the skin redraw to 5 fps it is around 10% again, but I think this is unacceptably choppy. I like the new skin engine and feel, but I'd also like to be able to use my laptop in a radio studio without the fan at maximum RPM.
Given the dilemma, for now I'll stay at VDJ 7.4, which is fluid and responsive at only 10% CPU. Some optimisation may be called for.
Posted Sun 08 Jun 14 @ 4:42 am
hbessems
By the way: the numbers I posted were just the numbers by VirtualDJ's executable, not the entire CPU.
Posted Sun 08 Jun 14 @ 4:45 am
djles.co.uk
I've reduced mine from 30fps to 20fps, still fairly smooth graphics but reduced a third of the work for the processor. Hopefully it should be enough to lower the temperature to be able to use it in my very hot Friday residency. The ideal would be to install aircon in the venue, but, not a chance of that happening. There's eight Cerwin Vega speakers and only two with working horns. Nothing gets maintained, so, aircon is just a pipe dream. :-(
Posted Sun 08 Jun 14 @ 10:47 am
rlove
Reducing the FPS from 30>20 still keeps the machine overly hot. This is one of the key factors on why I refuse to use V8 right now.
Posted Wed 11 Jun 14 @ 8:59 am
Don Moir
It's not a really a matter of us having to reduce the FPS for skins. I have mine set at 5 now, so I don't overheat and shut down. It's matter of them fixing this problem and don't have a clue why they elected to redraw the entire skin at some frames per second. Yes certain areas need to be time based but not the whole skin. Should never have happened in the first place but should be a priority one thing for them to fix hopefully.
There are some rough edges yet, but VDJ8 is pretty cool (except hot when redrawing the entire skin :) The skin redrawing is just something I noticed and could be some other areas need performance improvements as well.
There are some rough edges yet, but VDJ8 is pretty cool (except hot when redrawing the entire skin :) The skin redrawing is just something I noticed and could be some other areas need performance improvements as well.
Posted Thu 12 Jun 14 @ 1:31 am
Gerrit Beul
on windows redrawing the hole skin is normal for standard grafik even if you move onle the mouse. they call it worked as designed.
but thats belong to MS and that was the way V7 also woks copy red bar from position x to y and refresh screen.
in v7 they use spezial skin regarding the size of your screen eg 1280x800 so calculating were the bit should placed was less cpu intens!
in v8 they use the a standard size (full HD) 1920x1080 your computer has to do now to things at ones
copy red bar from x to y and
find the correct position in an reduced raster
thats what makes the skin still so cpu intens
please just try the skin from dennyo wich is 1366x768 and you will see less cpu if you have a sreen resolution near that value
if you screen is exact that 1366x768 than it should be like in V7
in MAC OS there is normaly no need of that windows way of screen display because it relay on Linux(BSD)
but Mac Version is a Windows Port!
wich means they also do it in the windows standard way
thats the problem with UNICode Base (one Code for all)
Info for FPS:
30fps is like 60Hz (wich called nearly fliker free in TV)
25fps is like 50Hz (wich was the old Televison and Cinema refreshrate (you will see flikering)
if you enter 50fps 100Hz (wich is flikerfree your CPU has to calculate so much that you need a very fast GPU and allot of memory)
best regrads
Gerrit
but thats belong to MS and that was the way V7 also woks copy red bar from position x to y and refresh screen.
in v7 they use spezial skin regarding the size of your screen eg 1280x800 so calculating were the bit should placed was less cpu intens!
in v8 they use the a standard size (full HD) 1920x1080 your computer has to do now to things at ones
copy red bar from x to y and
find the correct position in an reduced raster
thats what makes the skin still so cpu intens
please just try the skin from dennyo wich is 1366x768 and you will see less cpu if you have a sreen resolution near that value
if you screen is exact that 1366x768 than it should be like in V7
in MAC OS there is normaly no need of that windows way of screen display because it relay on Linux(BSD)
but Mac Version is a Windows Port!
wich means they also do it in the windows standard way
thats the problem with UNICode Base (one Code for all)
Info for FPS:
30fps is like 60Hz (wich called nearly fliker free in TV)
25fps is like 50Hz (wich was the old Televison and Cinema refreshrate (you will see flikering)
if you enter 50fps 100Hz (wich is flikerfree your CPU has to calculate so much that you need a very fast GPU and allot of memory)
best regrads
Gerrit
Posted Thu 12 Jun 14 @ 4:52 am
Don Moir
Gerrit Beul wrote :
on windows redrawing the hole skin is normal for standard grafik even if you move onle the mouse. they call it worked as designed.
but thats belong to MS and that was the way V7 also woks copy red bar from position x to y and refresh screen.
but thats belong to MS and that was the way V7 also woks copy red bar from position x to y and refresh screen.
It's not normal for anyone that I know of and been doing dev a very long time. Your saying then it is normal for a program to just to eat up the CPU when it is doing nothing and for no reason at all? What programs are those? I only have one that does that and that's VDJ8.
I guess I should expect a ridiculous comment like this. It's just a bad design and I am not going to go on a wild goose chase looking for skins.
Posted Thu 12 Jun 14 @ 5:07 am
Gerrit Beul
the problem leis in the DNA from Microsoft.
when you open a terminal session (RDP) and try to watch a video thru that session you will see the constant screen refresh.
normaly recent Computer are fast enove to handel that when you on a normal monitor but here you not only doing a screen refresch you also dowing the resize.
maby also the switch from the BPM source to PGN is causing a higher CPU Load?
S* and T* use a bulid in grafik that relay on the Code it self (but you could not have custom skins)
i gues a skinrezizer for V8 will fix the problem a litle bit
when you open a terminal session (RDP) and try to watch a video thru that session you will see the constant screen refresh.
normaly recent Computer are fast enove to handel that when you on a normal monitor but here you not only doing a screen refresch you also dowing the resize.
maby also the switch from the BPM source to PGN is causing a higher CPU Load?
S* and T* use a bulid in grafik that relay on the Code it self (but you could not have custom skins)
i gues a skinrezizer for V8 will fix the problem a litle bit
Posted Thu 12 Jun 14 @ 6:02 am
Don Moir
Not sure what else to say. Whatever is causing the problem needs to be fixed. We have far more complicated programs running with multiple videos, images, lasers firing off, and an extensive UI. When it's idle it's idle. No CPU impact. It only draws what is necessary at the time it needs to be drawn. Not as some FPS... big smiles :) So you have a steady drain on the CPU just from redrawing the screen 30 times per second say. Add to this the video and audio playback and anything else going one. This makes for a poor performer, but I can fry an egg on my computer now :)
I have 2 very fast machines sitting next to me. I use my slower machine for development so I can key in on stuff like this right away. Doesn't every developer? Well we know that the is answer is no and they get to feeling good about it and say: "hey it works fine for me, Jim how is it doing on your cray? Really good man, keep up the good work" haha
It could be more then just screen display, but whatever it is, needs to get the boot. When I first ran Serato, It had a heavy CPU impact and though it sucked. Is that the model for redraw you are talking about?
It won't do any good to point fingers. 2 years ago or day one this should have been considered as important but guess not.
I have 2 very fast machines sitting next to me. I use my slower machine for development so I can key in on stuff like this right away. Doesn't every developer? Well we know that the is answer is no and they get to feeling good about it and say: "hey it works fine for me, Jim how is it doing on your cray? Really good man, keep up the good work" haha
It could be more then just screen display, but whatever it is, needs to get the boot. When I first ran Serato, It had a heavy CPU impact and though it sucked. Is that the model for redraw you are talking about?
It won't do any good to point fingers. 2 years ago or day one this should have been considered as important but guess not.
Posted Thu 12 Jun 14 @ 6:30 am
Don Moir
By the way, I am a fan of VDJ. I want to see it work well and it's just so disconcerting to see something like this. When I don't care anymore, I will be silent.
Posted Thu 12 Jun 14 @ 7:18 am
rlove
Perhaps when VDJ actually overheats a machine which causes physical damage and the customer looks for restitution will they really pay attention to this issue. (This has been a problem since day 1.)
As noted, sorry about being hypercritical about this, however the fixes that the last few releases have brought are minor compared to the level of impact.
I've been called 'mean' on these forums in the past, which I'm truly not... However, I'm just overly annoyed at the level of arrogance that Atomix has when dealing with their paying customers.
As noted, sorry about being hypercritical about this, however the fixes that the last few releases have brought are minor compared to the level of impact.
I've been called 'mean' on these forums in the past, which I'm truly not... However, I'm just overly annoyed at the level of arrogance that Atomix has when dealing with their paying customers.
Posted Thu 12 Jun 14 @ 9:10 am
the SOUND INSURGENT
Haha might be time to up the price with all the new stuff you've added. Surely it's helped these guys and their shows, I know it has added value to my shows......
Posted Thu 12 Jun 14 @ 1:21 pm
RadiOnlineChile
this bug is caused due a wrong implementation of the hardware acceleration.
and due this, VDJ can't handle some GPUs properly, so instead of redraw the skin by the GPU, it's will start to redraw the skin by CPU which of course is more slow, and for that reason it eats 50% CPU even if you are not doing anything with VDJ.
in Windows, GDI and Direct2D are used for hardware acceleration, and probably VDJ is using one of them (I hope the best one), but to use one of them, your GPU should be WDDM 1.1 or newer, otherwise CPU will be used, and is more slow.
trouble is that not all the GPUs are WDDM 1.1, some are still XPDM or WDDM 1.0 (mostly the ones designed for Windows XP or Vista), and VDJ fails to handle hardware acceleration with XPDM or WDDM 1.0 GPUs (for example in a Geforce 7300GT).
I hope VDJ developers can find a way (maybe using some options depending of the WDDM of the GPU) to make redraw skin properly even in XPDM or WDDM 1.0 GPUs (like in others DJ softwares) and without consume 50% CPU.
for now the only way to solve this, is changing "maxSkinFPS" to 15 & "songLoadPriority" to idle (both options are in advanced options).
and due this, VDJ can't handle some GPUs properly, so instead of redraw the skin by the GPU, it's will start to redraw the skin by CPU which of course is more slow, and for that reason it eats 50% CPU even if you are not doing anything with VDJ.
in Windows, GDI and Direct2D are used for hardware acceleration, and probably VDJ is using one of them (I hope the best one), but to use one of them, your GPU should be WDDM 1.1 or newer, otherwise CPU will be used, and is more slow.
trouble is that not all the GPUs are WDDM 1.1, some are still XPDM or WDDM 1.0 (mostly the ones designed for Windows XP or Vista), and VDJ fails to handle hardware acceleration with XPDM or WDDM 1.0 GPUs (for example in a Geforce 7300GT).
I hope VDJ developers can find a way (maybe using some options depending of the WDDM of the GPU) to make redraw skin properly even in XPDM or WDDM 1.0 GPUs (like in others DJ softwares) and without consume 50% CPU.
for now the only way to solve this, is changing "maxSkinFPS" to 15 & "songLoadPriority" to idle (both options are in advanced options).
Posted Mon 16 Jun 14 @ 8:17 pm
Don Moir
All that's a bunch of BS. It's just a bad design... That's It !
Posted Mon 16 Jun 14 @ 8:52 pm
RadiOnlineChile
is not BS, you can read about this in Microsoft website: http://msdn.microsoft.com/en-us/library/windows/hardware/ff553819(v=vs.85).aspx & http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480(v=vs.85).aspx
Posted Tue 17 Jun 14 @ 3:47 pm
Don Moir
There is no other app I know of effected by what you are saying. There is no other app I know of that has to redraw it's entire skin at some FPS. Only changed regions are normally redrawn.
Not trying to put anyone down here. I just hate to hear excuses for things like this. I hoped it would be fixed rather then pointing fingers somewhere else.
If you use a method that causes problems, you don't use that method.
Not trying to put anyone down here. I just hate to hear excuses for things like this. I hoped it would be fixed rather then pointing fingers somewhere else.
If you use a method that causes problems, you don't use that method.
Posted Tue 17 Jun 14 @ 5:13 pm
sureview
if my machine was crashing due to heat at high cpu loads I would be checking my hardware, what's the point of having lots of cpu grunt if you can't use it ?
Posted Thu 19 Jun 14 @ 2:54 am
Don Moir
sureview wrote :
if my machine was crashing due to heat at high cpu loads I would be checking my hardware, what's the point of having lots of cpu grunt if you can't use it ?
Sure, but the high CPU loads are artificially caused by VDJ8. I have 2 fast machines sitting next to me but just a case of sloppy coding here. You don't waste CPU just because you can and this is what happens in VDJ8. Now I think everyone should be using a fast machine for this kind of an application to begin with, but on a slower machine, the wasted skin redrawing, the video and audio decoding, etc adds up to heat. The GPUs get red hot, add the CPU heat in a in compact computer like a laptop and it is designed to shut down to avoid damage. I had a GPU literally melt in one of my tower computers.
It's like saying my car should always run at 50,000 RPM even though I am only going 10 miles per hour.
Since you have this case where the entire skin is redrawing at some FPS (which is pretty much never done), you have to ask what else in VDJ is also less than optimal.
Posted Fri 20 Jun 14 @ 8:00 am
rlove
Don,
I'm a software designer/developer and have been writing software for over 20 years now and I agree with your statements wholeheartedly. With the advent of faster, multi-core processors, there's some 'luxury' which is taken to eat up superfluous cycles incessantly. I've tossed a debugger onto the executable and have identified exactly where the app goes wrong and kills the CPU/GPU, however I don't have the source code to fix it. (I've estimated that I could re-write the screen draw routine and a few other inefficiencies in about a day or two.)
While I am at it, I'd love to also fix the playing of DRM files (Zune, Rhapsody, etc.) as well...
I'm a software designer/developer and have been writing software for over 20 years now and I agree with your statements wholeheartedly. With the advent of faster, multi-core processors, there's some 'luxury' which is taken to eat up superfluous cycles incessantly. I've tossed a debugger onto the executable and have identified exactly where the app goes wrong and kills the CPU/GPU, however I don't have the source code to fix it. (I've estimated that I could re-write the screen draw routine and a few other inefficiencies in about a day or two.)
While I am at it, I'd love to also fix the playing of DRM files (Zune, Rhapsody, etc.) as well...
Posted Fri 20 Jun 14 @ 10:04 am
