I'm writing an application in LabVIEW which uses the Google Earth Plugin to display events on the globe. Each event is a single point kml placemark with an icon which is a 3kb png file. Placemarks are uploaded to the plugin as they are received by the software. I am experiencing increasing CPU usage with the number of placemarks that are added.
I have tested displaying a new placemark every second and running until the software running the plugin completely froze. The GEPlugin stopped responding (i.e. the globe did not respond to the mouse) at around 1200 placemarks added and CPU usage was at ~30%. When the software itself froze the plugin was using around 50% CPU and ~3700 placemarks had been added). After the freeze, no new placemarks were added which caused the software to respond (but not the plugin) so I could clear all the placemarks. After the placemarks were cleared then the CPU usage of the plugin returned to around 5% CPU.
So what I've seen is that GEPlugin CPU usage increases linearly with each kml placemark added. Is this the expected behaviour/ a normal limitation of the plugin? If not is there a more efficient way of adding many placemarks to the globe?
I am using GEPlugin version 7.1.1.1580 (API version 1.010) and LabVIEW 12.0f3
Thanks
Related
I have developed a sample for a potential problem in map.remove().
See: https://jsfiddle.net/moricio/e2wvwgu8/1/
This sample will choose a random lat/lng and will display a map centered at that point. It will wait 10 seconds before removing the map and generating a new position. It does this over and over.
If you open this sample in Chrome and check the Chrome task administrator(Shift-Esc) you will notice at each remove/add pair that the memory used by the tab will increase until your system crawls after a few hours.
Bug or my mistake?
This is a known issue in Leaflet - see https://github.com/Leaflet/Leaflet/issues/5263 and https://github.com/Leaflet/Leaflet/pull/5265 . Before that change, any L.Canvas or L.SVG (including the default one) were leaking quite a lot of memory. In Leaflet releases after that change, you should only experience a leak in one (hard to locate) circular reference to an instance of L.Draggable, which shouldn't be a big problem.
How to get screenshot of graphical application programmatically? Application draw its window using EGL API via DRM/KMS.
I use Ubuntu Server 16.04.3 and graphical application written using Qt 5.9.2 with EGLFS QPA backend. It started from first virtual terminal (if matters), then it switch display to output in full HD graphical mode.
When I use utilities (e.g. fb2png) which operates on /dev/fb?, then only textmode contents of first virtual terminal (Ctrl+Alt+F1) are saved as screenshot.
It is hardly, that there are EGL API to get contents of any buffer from context of another process (it would be insecure), but maybe there are some mechanism (and library) to get access to final output of GPU?
One way would be to get a screenshot from within your application, reading the contents of the back buffer with glReadPixels(). Or use QQuickWindow::grabWindow(), which internally uses glReadPixels() in the correct way. This seems to be not an option for you, as you need to take a screenshot when the Qt app is frozen.
The other way would be to use the DRM API to map the framebuffer and then memcpy the mapped pixels. This is implemented in Chromium OS with Python and can be translated to C easily, see https://chromium-review.googlesource.com/c/chromiumos/platform/factory/+/367611. The DRM API can also be used by another process than the Qt UI process that does the rendering.
This is a very interesting question, and I have fought this problem from several angles.
The problem is quite complex and dependant on platform, you seem to be running on EGL, which means embedded, and there you have few options unless your platform offers them.
The options you have are:
glTexSubImage2D
glTexSubImage2D can copy several kinds of buffers from OpenGL textures to CPU memory. Unfortunatly it is not supported in GLES 2/3, but your embedded provider might support it via an extension. This is nice because you can either render to FBO or get the pixels from the specific texture you need. It also needs minimal code intervertion.
glReadPixels
glReadPixels is the most common way to download all or part of the GPU pixels which are already rendered. Albeit slow, it works on GLES and Desktop. On Desktop with a decent GPU is bearable up to interactive framerates, but beware on embedded it might be really slow as it stops your render thread to get the data (horrible framedrops ensured). You can save code as it can be made to work with minimal code modifications.
Pixel Buffer Objects (PBO's)
Once you start doing real research PBO's appear here and there because they can be made to work asynchronously. They are also generally not supported in embedded but can work really well on desktop even on mediocre GPU's. Also a bit tricky to setup and require specific render modifications.
Framebuffer
On embedded, sometimes you already render to the framebuffer, so go there and fetch the pixels. Also works on desktop. You can enven mmap() the buffer to a file and get partial contents easily. But beware in many embedded systems EGL does not work on the framebuffer but on a different 'overlay' so you might be snapshotting the background of it. Also to note some multimedia applications are run with UI's on the EGL and media players on the framebuffer. So if you only need to capture the video players this might work for you. In other cases there is EGL targeting a texture which is copied to the framebuffer, and it will also work just fine.
As far as I know render to texture and stream to a framebuffer is the way they made the sweet Qt UI you see on the Ableton Push 2
More exotic Dispmanx/OpenWF
On some embedded systems (notably the Raspberry Pi and most Broadcom Videocore's) you have DispmanX. Whichs is really interesting:
This is fun:
The lowest level of accessing the GPU seems to be by an API called Dispmanx[...]
It continues...
Just to give you total lack of encouragement from using Dispmanx there are hardly any examples and no serious documentation.
Basically DispmanX is very near to baremetal. So it is even deeper down than the framebuffer or EGL. Really interesting stuff because you can use vc_dispmanx_snapshot() and really get a snapshot of everything really fast. And by fast I mean I got 30FPS RGBA32 screen capture with no noticeable stutter on screen and about 4~6% of extra CPU overhead on a Rasberry Pi. Night and day because glReadPixels got was producing very noticeable framedrops even for 1x1 pixel capture.
That's pretty much what I've found.
Here I've taken two heap snapshots in chrome dev tools and switched it to "comparison mode" so I can see the deltas between the two snapshots:
Notice that the first heap snap shot is 92.3mb and the second is 275mb (as indicated under "Snapshot 1" and "Snapshot 2" on the left). This is a size increase of 182.7mb.
In the right-most column, the size deltas for each constructor are listed (in bytes). If we sum these up we get a net increase of about 500kb.
How could this be? Shouldn't the size deltas sum be the same as the size difference between the snapshots? If you look at the chrome heap snapshots tutorial in the "Comparison View" section, there's a screenshot that shows what you'd expect: the size deltas sum to the change is snapshot size.
Note: I'm actually using the --inspect option of nodejs, so this isn't the regular chrome devtools, but it looks like it's essentially the same software (and maintained by the same team), just slightly adapted to nodejs, so I'm keeping it general by not tagging nodejs, etc.
Edit 1: I followed #wOxxOm's advice from the comments (click garbage bin icon before snapshot) and got a 60mb snapshot vs a 300mb snapshot, but when I clicked the mode dropdown and selected "comparison" to get the deltas I got this message (you'll probably need to open the image in a new tab to read it):
I'm beginning to think this may have to do with nodejs, and it seems like it's not just something I misunderstood about DevTools, so I'll add some extra details which might be clues as to what's going on:
I'm using node-webworker-threads which implements the WebWorker API in nodejs using native threads.
I'm passing these "workers" 10mb chunks of text to be processed and then have metadata returned to the main thread and aggregated. The text is being pumped into the pool of workers at about 5mb/s.
When I clicked the garbage bin icon as #wOxxOm suggested, my computer's RAM usage didn't seem to drop.
On this page it says "Only reachable objects are included in snapshots. Also, taking a snapshot always starts with a garbage collection." Could it be that the snapshot size is taking into account the RAM used by the workers, but the actual table of constructors + deltas only lists "reachable objects" in the main thread?
Here's a pie graph of the memory usage.
In my website I have a viewer that loads huge 200mb pictures (millionsXmillions of pixels).
With that, on screen the client never sees more than say 1600x900 pixels at a time.
Loading the full image seems to be a huge toll on the browser, actually often my tab crashes when I try to load a picture that is too big.
How do I go about serving only the visible part of the image? (serving a section of image by coordinates)
If the image was scrolled left by 100px, I want to serve the new 100px only, not the entire 1600x900 section that includes those 100px. Meaning, that the client needs to know what section it already has, and only requests for the new section that it lacks.
I would like to unload parts of the image from the client after a certain period of time.
(Yes, very similar to the way google maps work)
Any tips on what to read? where to look? What approach I should attempt?
I am using node.js with graphicsmagick.
How do you know if the (free) GoogleEarth App is still loading data or hasnt crashed for some reaons.
Im loading a huge kml file, 100% cpu usage, but it never stops processing..
Are there any limits about the KML size of the displayed file?
How many KML MBs the Google Earth PC application can show without crashing ?
I don't think there are any file size limitations for Google Earth when using .kml files. There is however limits with regard to the size of images, so if your kml is trying to load images (such as screen overlays) then perhaps your problem lies there.
This is related to the specifications of your computer, so you can find the maximum resolution of images you can import by looking under the 'About'. I am not sure where to find info about the kb size of the image.
Next, you can try creating a .kmz out of the .kml - A KMZ is simply a compressed file the same as a .zip is - learn more about it
http://code.google.com/apis/kml/documentation/kmzarchives.html
Also you can try breaking the file up into smaller ones, either by using network links
http://code.google.com/apis/kml/documentation/kmlreference.html#networklink
or Regions
http://code.google.com/apis/kml/documentation/regions.html
By breaking the file up into smaller ones, you might also discover which part/element of the KML is causing hassles if you have some kind of format error