Forum: VirtualDJ Technical Support

For reporting any bug, questions or comment related to the latest version of VirtualDJ
(NOTE: VirtualDJ continuously updated, so many older topic on this forum are most probably already fixed in the current build)

If you need extended support, contact our Support Team.
Forum Guidelines  (*) The moderators hold the rights to move or modify posts in order to keep the discussions clear or to facilitate the search.
Topic: Screen Diming using Touch Screen

Questo argomento è obsoleto e potrebbe contenere informazioni obsolete o errate.

This is part of an existing problem with VideoForceFullScreen=1
It seems part of this problem has been addressed and if i use my mouse to bring up menus, the screen dosent 'dim' and i can use the =1 setting.
BUT if i use the TouchScreen (3M Microtouch) if anything pops up (Rightclick, Load Security, etc) the screen dims and if this happens too often the skin engine fails and stops drawing the skin stopping us from using the program..

The quick fix is to use =0 for now but ive been using =0 from the start and VOB files very often suffer from a 'tearing' effect on playback so hardly ideal.

Inviato Fri 29 Jul 16 @ 1:12 pm
AdionPRO InfinityCTOMember since 2006
If you use videoForceFullScreen 1 and the video output is active, then there is only 1 interface window, which will show pop-ups as well (with dimmed background of the skin)
It doesn't matter if the window popped up because of mouse, touch-screen or controller.

If you can find the steps to reproduce any problem where the skin is not responding or updating anymore after such a popup, let us know so it can be fixed.

Inviato Fri 29 Jul 16 @ 6:18 pm
I'm not sure how otherwise you want me to describe how this happens..
When the screen dims, vdj skin engine crashes.

I can get this to happen with the video engine NOT RUNNING..

If you have windows UAC enabled and open something that invokes UAC (then the screen dims) it then crashes the skin..

and also ive noticed clicking on manually add device in remote app config (in vdj main program) the popup for the ip address dosent show but the config screen is stuck "behind" something that didn't appear.

I don't want to have to re-install windows AGAIN to remove some glich that might be attributed to windows :(

Inviato Sun 14 Aug 16 @ 7:30 pm
Just messing with master output by continuous clicking eventually caused it to crash. May have something to do with also bringing up the options dialog in between. Was not difficult to cause problems with it but don't have exact steps except clicking master output. Locked up once and crashed once in a matter of minutes.

Inviato Sun 14 Aug 16 @ 9:37 pm

Inviato Fri 19 Aug 16 @ 8:35 am
and so this continues into build 3398 (and all between too)
from starting VDJ I can still make it misbehave!!
set videoForceFullScreen = 1
Irrelevent of FPS, videoMaxMemory, videoUseDVVA...

load a video, open the full screen video out on 2nd monitor, play the track.. then do a right-click on any track in center of browser..
at this point the right-click menu always opens "centered" and dragging any track (in grid view) is impossible.
dragging from side list still works at this point but I have no way of getting tracks to the sidelist now as center browser is inoperable.

This is happening using the touch screen (Microtouch) the conventional mouse DOES work BUT as the problem happens after the screen DIMs the mouse does not cause this behaviour. (I don't DJ with the old mouse, I'm 100% touchscreen)

Inviato Tue 13 Sep 16 @ 1:36 am
marksmolinski wrote :
and so this continues into build 3398 (and all between too)
from starting VDJ I can still make it misbehave!!
set videoForceFullScreen = 1
Irrelevent of FPS, videoMaxMemory, videoUseDVVA...

load a video, open the full screen video out on 2nd monitor, play the track.. then do a right-click on any track in center of browser..
at this point the right-click menu always opens "centered" and dragging any track (in grid view) is impossible.
dragging from side list still works at this point but I have no way of getting tracks to the sidelist now as center browser is inoperable.

This is happening using the touch screen (Microtouch) the conventional mouse DOES work BUT as the problem happens after the screen DIMs the mouse does not cause this behaviour. (I don't DJ with the old mouse, I'm 100% touchscreen)


EDIT: I'm using a custom sidelist and its fine from there but not working in DEFAULT skin, from correct side list or center browser!!!

Turning off use fullscreen video to =0 after restarting virtualdj banishes the issue, but surely video=1 is supposed to be better??

Using NVidia and / or Intel graphics does the same :(

Inviato Tue 13 Sep 16 @ 1:42 am
AdionPRO InfinityCTOMember since 2006
Videoforcefullscreen is not supposed to be better. It comes with the limitations you noticed.
If you don't have problems it's recommended to leave it at 0

Inviato Tue 13 Sep 16 @ 6:05 am
I would say it is buggy, lockups, interface stops working (2 versions of it at least), effects stop activating or deactivating, screwy UI behavior, etc. Did you try Direct3D9Ex for the skin? I use it and helps to avoid full screen issues with Direct3D9. Of course you would still need to use Direct3D9 for video so as to not break things but the skin is pretty much isolated. The limitations can probably be eliminated.

Inviato Tue 13 Sep 16 @ 4:17 pm
How do I use Direct3D9Ex for the skin?

Inviato Wed 14 Sep 16 @ 11:50 pm
You don't use Direct3D9Ex. That is for internal coding and a choice Atomix could make to draw the skin. From Vista up, the d3d9.dll includes Direct3D9Ex and is an upgraded version from Direct3D9. They made some things better and got rid of managed elements. It is an easy transition and an easy thing to test.

Inviato Thu 15 Sep 16 @ 1:56 am
So what is the =1 mode and why have I read that it was supposed to be better than =0 mode (which I believe is "windowed" mode - expanded to fill screen)

Inviato Thu 15 Sep 16 @ 2:18 am
The =1 mode is hardware full screen mode. In this mode it does not need to behave like a window with it's various needs of a window so more efficient. In the =1 mode you target a specific monitor with no moving around etc. The =0 mode is window mode and generally is easier to deal with both for internal coding and for end users since it easy to move it around etc.

One problem with window mode is tearing and scene best when doing horizontal scrolling. One cause of this in window mode is normally the code usually chooses the default monitor for the display device which will be monitor 0. The default monitor is normally where all your icons lives and where you generally navigate. Monitor 0 is selected when you select some monitor as you main display.

Now say your video is on some other monitor. It might be monitor 1 but not monitor 0. But the code has selected the default monitor for it's video display device. So what Direct3D9 does, is it checks for vertical sync on the monitor you don't care about for video, monitor 0. Our video is on monitor 1. In window mode you can also target a specific monitor and it helps a lot. But problems can occur when moving the video window to a different monitor.

It varies from one os to another and depends on your GPU etc. You can't really wrap it all up into one neat little answer. I just think they are spending too much time on things that don't really work when it is not that difficult to support the =1 mode and keep everything clean and normal.

Inviato Thu 15 Sep 16 @ 3:00 am
I changed all my own code to use either Direct3D9 or Direct3D9Ex depending on use case and availability. They are so close that most code remains identical. I did this quite some time ago because of problems with hardware full screen mode. Direct3D9 wants to own everything when in hardware full screen mode. Direct3D9Ex fixes that.

Direct3D9Ex also makes lost devices mostly a thing of the past. A lost device just about never occurs no matter what you do using Direct3D9Ex. Don't worry if you don't know what this means, it is for internal coding only.

Direct3D9Ex removes managed resources so that is the reason VDJ could not use it for it's video device. It would be a problem because some plugins depend on managed resources and it would break that.

Since the skin is only only drawn by VDJ though, it could use Direct3D9Ex. The problem with it now is like I said. Direct3D9 wants to own everything when just one thing is in hardware fullscreen mode. So when they try to use that for skin drawing it is a problem.

I also use Direct3D for drawing my layout screen in TellyVisuals but it uses Direct3D9Ex and no problem if VDJ is in hardware fullscreen mode. The code that draws the layout screen in TV and the code that draws to the VDJ video screen is exactly the same even though one is using Direct3D9 provided by VDJ and one is using Direct3D9Ex. The main difference is in the way resources are created. D3DPOOL_MANAGED cannot be used in Direct3D9Ex.


Inviato Thu 15 Sep 16 @ 3:17 pm
There's a lot of helpful info here for the devs to consider, I just hope they can fix the code soon :)

Inviato Thu 15 Sep 16 @ 4:01 pm
AdionPRO InfinityCTOMember since 2006
The main reason it's not a high priority to fix is that for most users there will not be any problem with simply leaving forcefullscreen to 0.
Tearing is only an issue on xp, when you disable aero or if you didn't update your video drivers properly.
Performance is only an issue if you are using an atom or integrated cpu graphics older than 5 years or so.

Inviato Thu 15 Sep 16 @ 4:26 pm
Adion wrote :
The main reason it's not a high priority to fix is that for most users there will not be any problem with simply leaving forcefullscreen to 0.


You been dicking around with it since VDJ8 came out and certainly that has caused a lot of headaches and time wasted for you and others when there is an easy solution for it. People still use =1. I would think it would not take you more than one day to try Direct3D9Ex. As it stands you will still need to waste time when something does not work in =1 mode. And very easy to break things in that mode. So it is broken and needs to be passed on to support which probably does not have a clue what that is all about. I also have to waste time dealing with it when an end user is having a problem. I have them try everything and sometimes nothing works for them except the =1 mode.

Adion wrote :
Tearing is only an issue on xp, when you disable aero or if you didn't update your video drivers properly.


If aero is on then it does fix the tearing but that does not mean it if flawless. I get stutter with it when using VDJ. I have to tell you though that I have a new cheap non integrated GPU currently. I don't go by that alone though. I go by what other uses say who need it to work for real. When I get a new GPU or new machine I will test it all again. I have a fast CPU but low end GPU currently. Here I am in small beach town and had to get a GPU card quick and that was the best they had.

Outside of tearing issues, the thing that hurts the most for me is the skin drawing. No mode helps with that. Are you trying to draw the video and skin in same thread with same device? That bangs head with the video display and is terrible when the skin is not minimized. I also do not like using aero but it is a choice for some users to make.

PS: Would be good also if you looked at the lost device issue where skin goes black and stays black after ctrl-alt-del to bring up task manager. This in windows mode. You would not get a lost device if you were using Direct3D9Ex but is easily handled in Direct3D9 for most.

Inviato Thu 15 Sep 16 @ 6:48 pm


(Vecchi argomenti e forum sono automaticamente chiusi)