Has anyone experienced a very slow resume when closing the dashboard of swarm? There is about a 5 second delay in my application where a black screen is displayed after the dashboard is closed and before the actually game screen is rendered. I had originally thought that maybe my show() method for the current was doing too much and causing the lag, but after looking a bit closer I see that the show() method is actually never even called when switching from the swarm dashboard back to the game, I suppose this is due to the fact that Swarm is not operating in a libgdx context but an android one.
Any help appreciated.
That's OpenGl context Loss. your assets need to be reloaded. If you have a lot of assets, you should separate them and load them when needed. That will help your game to feel much faster, especially when starting and when coming back from swarm dashboard.
Related
At some point of development of my new game, I stumbled upon a problem which lead me to discovery of Adobe Scout. The problem occurred after some time of gameplay when the game started lagging more and more heavily up to the point when the whole application crashed. I did some profiling with Scout, and here's what I found: most, if not every heavy memory load is caused by gotoAndPlay() function (if I understand the data presented by the profiler correctly). This function always seemed and even felt like an easy task for Flash, but turns out it's not? Or is it caused by using text labels instead of frame numbers? I am currently looking for possible workarounds to use this method less, and while I do, it would be infinitely helpful to hear thoughts or possible options from people who are aware of this issue.
I've completely failed to understand the reason why i get this exception so it would be nice if someone would be so kind to look at my project and suggest any reasons for the issue. I understand it's quite difficult to look at unknown project so even any tips would also be nice.
Problem description: i've ported my own ZoomControl from WPF to StoreApp and use it to zoom in/out graph using ScaleTransform. When i work on default/far zooming level all seems fine and no memory spikes occur but as i zoom-in deeper unmanaged memory usage burst very high and fast resulting in OOM exception. I've profiled using dotMemory and tried to isolate different parts related to zooming including animation cut off and template simplifying to no avail.
Another strange thing i've noted: if you zoom in w/o crash and alt+tab to task Manager you'll see significant memory usage drop, then if you'll back to app and pan content with the mouse (don't touching zoom) you'll got lag and can see huge memory usage spike in Task Manager.
The weird thing is that it works fine on one zoom level and crash on the other, This is mind blowing. I just don't understand why there is so high memory usage in zoomed in state.
I'm working on open-source project you can get here. Run METRO.SimpleGraph project and use mousewheel to zoom in.
I'm quite new to Android development.
I'm trying to write an app that communicates by Wifi using UDP to an instrument.
The app plots 512 bytes of data it receives over WiFi using AndroidPlot. Transfer rate is satisfactory and communications is fault tolerant.
I would now like to turn my proof of concept into a functional app complete with tabs & swipe navigation.
On one tab I'd have my chart, on another tab I'd have some controls, and another tab with status information. Each tab would need access to the UDP thread.
As I'm new to this I'm having a hard time determining the right architecture to implement.
I feel I've wasted a good bit of time on fragments and pager adapters without really getting the functionality I'm after (the work I've done so far feels as though I'm trying to force something to do what it really isn't meant to do).
Could someone with experience give me a general path to take? Are fragments the answer? Is there a way to support swiped tabs without the additional complication of fragments?
Thanks for any help! Hopefully this isn't too general.
Sometimes, when I launch my game in LibGDX (the game doesn't require much power) the rendering is very laggy, but most of the time, when I run it the game runs smooth perfectly.
I would understand this if it would be laggy all the time, but it's laggy only in about 10% of the times when I run it. When I close it and run it again, it runs perfectly. Why is this happening?
I use Eclipse for launching and it runs as a desktop app.
I had the same problem. Try running it alone without Eclipse and it should work.
I experience this a lot it's not because of your libGdx project it's because of your computer. Computers just lag from time to time because of the multiple data or information they are handling everytime you're using it. Just ignore it man the important thing is you're making an awesome project, just don't mind the lag.
If you have a dual monitor setup, can you ensure there's no GPU activity on the other display? I noticed even with a decent setup, if something else was on my opposite monitor (eg., a chat client or a browser window) projects would run at a significantly slower framerate.
I opened this matrix multiplication benchmarks and my browser (Firefox 7.0.1) froze until the benchmarks finished (I opened the page in an old Asus EeePC 1000H).
I heard that web workers were invented to separate processing from displaying the web pages. Is it possible to make use of the Web Workers API to make WebGL not stall the whole web browser ?
For the sake of clarity: the benchmark that you linked to does not use WebGL at all. (I should know, I wrote it.) And in the case of that particular benchmark you absolutely could run it in a Web Worker now and it would be perfectly fine.
(Fun fact - Web Workers didn't support TypedArrays when the benchmark was built, and since most of the matrix libraries rely on that it was impractical to run it in a Worker at that time. That has since been fixed.)
Anyway, to answer your original question: No, WebGL cannot run in a worker. The core blocker to this is that in order to get a WebGL context you need to call getContext on a canvas element. Web Workers explicitly disallow DOM access (which is a good thing, BTW!) and as such you'll never be able to access WebGL from a worker.
But that's not as bad as you might think. For one, consider that most all 3D rendering is actually happening in a different thread anyway. Specifically, a whole bunch of threads running on your GPU. The only part the browser has in it is to tell your graphics driver "Hey! Start rendering some triangles using this data!" and then it moves on without waiting for the triangles to actually be rendered. As such, while the draw commands must be executed from the main process, the time it spends blocking that process is (usually) very little.
Of course, that's not what's going to eat up a bunch of your time if you were coding a realtime game. You've got animations, physics, AI, collision detection, pathfinding... there's a lot of non-graphical tasks involved that will eat your CPU alive if you let them. In some case (animation), it's usually just gobs and gobs of matrix math, just like the benchmark you linked to! Fortunately for us, however, that type of processing CAN be done in a Worker, and all we need to communicate back to the main thread is the data required to render the scene.
Yes, this introduces some challenges in terms of synchronization and data transfer, but on the whole it will be vastly preferable to locking up your browser while we try and simulate those 500 boxes colliding.
Yes, on Firefox!
https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/
We’re happy to announce WebGL in Web Workers in Firefox 44+! Using the new OffscreenCanvas API you can now create a WebGL context off of the main thread.
By default you can't use WebGL in a Web Worker as Toji explained.
You can check out WebGLWorker which is a library that lets you do WebGL stuff in a Web Worker, by transparently proxying commands to the main thread.
Here is a nice blog post that explains how it works.