I have two separate graphics cards on my machine (2x NVS 315) and three monitors attached to them (2 monitors on one card, 1 monitor on the other card).
To see how well my PixiJS code would perform when running side-by-side on multiple browser windows, I opened one Chrome window in each monitor.
To my surprise, the GPU handling my primary screen (GPU#1) was doing most of the work (100% usage really) while the other GPU (GPU#2) stayed at around 40% usage. This was still true even after I ran a browser window only on the monitor attached to GPU#2.
My expectation was that GPU #2 would do all the work when a browser window was rendered on the monitor attached to it. Apparently this is not case and GPU#1 was still on 70% usage while GPU#2 was on 40% usage.
To be honest, I'm pretty sure this is not an issue with PixiJS but rather an issue with Chrome/WebGL/OpenGL.
I then made a few experiments with other OpenGL games running in both windowed mode and fullscreen and saw the same behaviour. It seems the GPU associated with the primary screen always does most of the work.
I saw a possible explanation of this behaviour here: https://superuser.com/questions/731852/how-is-gpu-affinity-decided-in-a-multi-gpu-configuration#comment939363_731852
Is there any way in WebGL/PixiJS to specify GPU affinity?
Not as far as I know.
Very few apps switch GPUs. Almost all of them just use the primary GPU (as in default/first). Rendering happens on that GPU and then results are transferred to the other GPU so they can be put on the screen. Microsoft has a few examples of how to switch GPUs by checking which screen the window is mostly on but few apps that I know of use that. At best, a few games that go fullscreen will use the correct GPU for each screen.
Related
My Ms Access(2010) database uses forms to display and manipulate data. Recently, when presenting these, I found out that the use of these forms on a video projector leads to a severe problem, the forms appear to be 'zoomed' in.
Therefore I have 2 questions, thanks for the answer!
1) How are twips on a video projector calculated? Theoretically this should depend on the distance between projector and screen, which woulnd't make too much sense. (I'd need this information to be able to explain the problem, thank you very very much)
2) How can this be configurated? Is it possible to use VBA or Win32 API to achieve this?
I don’t think this problem has anything to do with TWIPS or with the video projector. Any monitor (analogue, digital, projector, etc.) shows the same picture if it has the same resolution. If you set the output of your computer to i.e. 1024 * 768 pixels and the output device (analogue or digital monitor, projector, etc.) uses the same native resolution then the picture will look the same on each device.
Access works in pixels. If you have a form optimized for a specific amount of pixels then this is what Access uses. If you have a higher resolution then form will not fill the screen and if you have a smaller resolution the form will not be completely shown on the screen.
I guess what happens is that you use on your PC an output of i.e. 1600 * 1200 pixels but your projector can’t show this correctly. So the projector tries to convert i.e. 1600*1200 to 1024*768 and this will never look good.
I think you have two options: Check the resolution which your projector expects and set your PC to the same resolution. Or change your application – or the projector.
In line with what Edgar has suggested, regardless of the display type (projector, monitor etc...) the issue will remain the same. In this scenario, the problem is the form is designed for a given screen size, say 1600x900 (16:9) or 1920x1200 (16:10) or whatever you have chosen to design the form as.
The projector is likely not the same resolution as this. Many smaller projectors are either 1024x768 or 1280x720, both of which are likely smaller than your computer monitor in regards to resolution. While it is true that you could design the forms to the proper pixel dimension of the projector an easier way, that wouldn't require editing any content, would be to send the projector the same resolution that you have designed the forms to be.
For example, if your forms fit nicely on a 1920x1080 pixel space but your projector is 1024x768 then you could open display preferences on your computer and set the output to the projector to be 1920x1080. The projector will then scale the image to fit onto its 1024x768 panel.
There are many variables in here and you may run into equipment limitation with this approach, such as the projector not being capable of ingesting and scaling a given resolution which you are forcing into it. In that instance you could utilize a hardware video scaler inline between the computer and projector to perform the scaling operation for you. An example of a device capable of this would be a Barco ImagePro, though there are many other more cost-effective solutions on the market as well.
Developing a Windows 8 Phone app.
I have noticed that there are these performance counters on the right hand-side of my device/emulator.
On my device the 3rd number - 35 (etc) is constantly displayed in a red font. On the emulator it is not (see image below). I am not too concerned about that as I am sure the emulator is not a direct parallel to a real device. What I am concerned about is that it is red on my device. Should I be worried about this?
Also, on a side-note on a previous StackOverFlow question What do the numbers mean in the upper right hand side of the emulator?
There are 6 different numbers.
I only have 4.
So, is this the surface counter? That would make sense as i am updating my img controls.
Any enlightenment would be great.
sd
I notice that fullscreen mode with LWJGL takes up a lot of resources. I looked at it with my profiler, and see that Display.update takes a considerable lot of time. Is there a solution for this? Is it a natural occurrence?
Display.update is the main method that contains all the pipeline logic with communication with OpenGL so by nature it is going to be the largest function of the application, much like Game.doLogic for instance. Because it contains all the OpenGL communication it is heavily influenced by OpenGL which in turn influences hardware, and obviously the larger the window the more pixels it has to draw, among other things, thus making the frame/render time longer and so finally influencing Display.update. So yes it is natural for it to take longer the bigger the frame's resolution.
How much more "resources" exactly? Does "resources" mean hardware or function timings or memory usage? I don't see much reason for Display.update to take up a noticeable amount of memory the larger the frame's dimensions.
Is there any way to be able to query the GPU to tell me if my viewport in my webpage is currently on screen or not? For example, if I had a 3d scene rendering in a canvas in an iframe, is there a way to query the hardware (within my iframe and only the pixels or verts in the viewport) to say if I am on screen or scrolled off screen?
I'm curious as to whether this is something I can do at the vertex shader level. Does WebGL even perform the shader program on a viewport that is offscreen? Lets say if it is scrolled below the canvas, or the viewport is obstructed by another webpage browser window? Is there a way to query the compositing portion of webgl to see if it is even in view or Iterate through the "RenderObject" Tree to test if it is even onscreen and then return this value? I am trying to get much more performance out of a project I am working on and I am trying to only render what is visible on screen.
Any possible ideas? Is this even possible? Thanks!
RequestAnimationFrame is only reasonable way to handle unnecessary performance loss even semantically because window.requestAnimationFrame tells the browser that you wish to perform an animation... So browser will figure out how it should handle your wish in optimal way taking into account current page state.
But since iframes communicate using local storage you can push to them your base page state so each of them will decide should it RequestAnimationFrame or not. But im not shure that it is a good thing to have multiply render contexts on your page, they all eat resources and can't share them (data that stored in GPU is sandboxed) so eventually they will start to push each other from GPU memory and cause lags + GPU pipeline might be not so happy with all those tiny standalone entities. Fragmentation is main GPU performance enemy.
You don't ask this question at the canvas/WebGL level, because it might, for example, be scrolled back on screen before you draw another frame, and browsers don't want to not have content to show, so there's no provision to not draw.
I believe you will have to consult the DOM geometry properties (e.g. .scrollLeft) of your scrollable areas to determine whether the canvas is visible. There is enough information in said properties that you can do this generically without hardcoding knowledge of your page structure.
Also, make sure you are exclusively using requestAnimationFrame for your drawing/simulation scheduling; it will pause animations if the page is hidden/minimized/in another tab/otherwise explicitly invisible.
I know you can fake full screen by expanding a window and eliminating the title bar , status bar , and other stuff, I'm not interested in this, I want to know about "real" full screen mode (I don't know how to call it else) , like in games.
what exactly is full screen mode?
what win-api should I use to achieve this?
can this be used to play movies in full screen ? I know windows media player uses a fake full screen because I can "cut" thru it and see the desktop (using regions win-api).
can I "cut" thru "real" full screen like I thru a window (using regions win-api) ore is this directly writing to video memory and there is nothing "under" it?
Thanks!
If you want to make games on Windows in full-screen, the best option is XNA. This uses DirectX underneath, but hides a lot of the implementation details and plumbing to make it easy for the developer to start working on his game.
XNA is freely downloadable, and has good documentation.
XNA Game Studio 4.0 can be downloaded here.
...and you might want to support the "fake" fullscreen mode in addition to "real" fullscreen - it's very nice for those of us that run multi-monitor systems.
If you don't want to use DirectX, create window and call ChangeDisplaySettings with CDS_FULLSCREEN flag. OpenGL applications use this way to go fullscreen.
As far as a user is concerned, full screen is just when a window takes up the entire screen such that they no longer see any window borders or other desktop stuff.
As you know, not all full screens are created equal.
'proper' full screen is where the program takes control of the screen. When a game uses this mode, it can change the resolution of you screen. If you have ever played an old game and existed to see your icons all messed up, this is; for the duration of playing the game, your desktop was at a lower resolution.
with 'borderless full screen' the program window is striped of any borders, the title bar and frame etc., and is just a rectangle of pure rendering. If you then set this rendering context to be the same size as your desktop, you get the effect of full screen.
Doing border-less is usually the more user friendly way these days, as it is easier to 'tab out' as the other programs are still graphically around. 'proper' full screen gives you full control of the hardware, so in theory you have more power for your program, but it means you have to wait for things to reinitialise when you tab out.
what you do with your rendering context is up to you, so yes, you can use it play videos. It would not matter if you are in 'proper' full screen or not, the rendering code would be the same.
As for cutting through proper full screen windows, I am not sure, but I think there would be nothing else to see, there is only your program.
as for what win-api, there is only one windows api, but I think you mean, what windowing library; as this is getting to be a long answer already, I shall just say it depends a lot on what you want from it.
Please feel free to leave comments if you need me to clarify or expand on any points.