Using kinetic js for a searchable directory listing on a kiosk. It works great!! except for one issue. I am in chrome and have an a,b,c,d etc list on the side a user can click for names starting with that letter. When a letter is clicked, it re-renders the whole stage. After 10-15 times of doing that, the stage comes up blank, but I can still click where a name would be and get its detail "lightbox" or click where a letter would be and get a new listing, but still a blank stage, ie no fill or color on any rects or text. Whats worse is that if I go to an entirely different kiosk page that uses KineticJS for something else, it does not render either and never will again unless I leave the domain (localhost) and go to google or something and come back, or open a new tab or restart Chrome. I am totally lost now and redoing it without Kinetic is going to be a huge loss if I can't figure this out.
I have gone through and tried to be sure my memory management was ok and pretty sure it is. My system memory does grow, but Chrome seems to gargbage collect it fairly quickly. I have even tried calling destroy() on every kineticjs object I create when re-rendering with no luck.
There is a known issue in Chrome 29 in regards to canvas rendering. The issue is not present in version 28 or 30. Join the party and help draw eyes to the issue. :) https://code.google.com/p/chromium/issues/detail?id=280153&thanks=280153&ts=1377616231#makechanges
As a temp workaround you can turn off the 2d canvas acceleration by setting 'Disable accelerated 2D canvas' flag to enable.
Related
I found [1] this issue on newest WebView of Chrome. To produce it you need three things:
You have updated WebView to version from 15.11.2021
HardwareAcceleration in AndroidManifest is set true
When you heavily give stuff to render for webview, you start to see missing content on screen.
My technology stack uses a Openlayers map inside app that is actually a small website packed with Cordova, which is the component that uses the WebView.
By heavy use I mean the map has to have many layers of map data on for rendering and I have to make some maneavours moving the map and making it to start loading next rendered content before the previous one is completed.
At first time I open the map after installation, the map works ok with heavy load. Issue starts when I kill the app and login again and make the heavy movements when the app tries to render the first time. After that the map does not render content as a whole, some tiles and map menus come only partially.
The behavior continues even when I click off some map layers, and when there is very little of them anymore, the issue settles down. Interesting point is also, there is no single point where the load is enough to trigger the issue or settle down, at least the point is different going to each direction.
There is a warning message, that comes to logcat only when the issue is present:
chromium: [ERROR:tile_manager.cc(821)] WARNING: tile memory limits exceeded, some content may not draw
and I can observe it to be coming along same lines the 15.11.2021 version update has removed some "useless data" [2]. I am not 100% sure if these two things are related, but I have realized the versions before that particular update work just fine with my app (I removed updates from WebView in Google Play).
There are currently three workarounds:
Do not use map layers that are too heavy and trigger the issue (makes bad for our app user experience by hiding crucial information from user)
Remove webview updates from PlayStore (I personally tested that, overnight the system updated the broken version back, hard to communicate to end users).
Not to use hardware acceleration. (Other parts of the app get useless, too slow behavior makes end users angry).
As you observe none of these is working well. I believe that this same behavior is seen by other WebView heavy users too, so I opened this question with only one main question:
Meanwhile my bug report is advancing in Google, what could I do meanwhile to overcome the issue?
Sources:
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1274482
[2] https://chromium.googlesource.com/chromium/src/+/a0994781ea666d9b630b6478206ac429ed8444d1%5E%21/#F0
We are creating an app that lets a user capture a number of images and it will try to create a 3D model of the target object. In order to help the users capture useful images we give them some guidance while they move their phone from one capture to the next.
We have a nice prototype working by means of navigator.mediaDevices.getUserMedia() that captures video, displays it in a <video> element, and has an overlay that shows how to move the phone. When they are ready they press a button and we grab the current frame of the streamed video.
We were quite happy with this until we realized that very often the captured image would not have enough quality; mainly they tend to be a bit blurred because the user may not hold the device totally still. This causes the math behind creating the 3D model to fail.
I am now tasked with attempting to improve this but I think I don't have many options. Here is what I have been investigating and their drawbacks:
JavaScript's ImageCapture API. This seems to be exactly what we need: a way to actually take a picture instead of grabbing a frame from a video. While the API has still an experimental status, it seems pretty stable and Chrome has it implemented since version 59. The problem is that Safari (our main target) does not have it implemented and it seems they won't ever do. I can't really find information on what their plan is though but as of today, this is not an option.
Use the input element of type file with the attribute capture. While this lets me capture images with the native camera, I cannot give the user any guide as far as I know.
Create a whole mobile app. This requires another year of work and requesting our existing users to install an app, which may not be possible. Also leaves Android devices out which we'd prefer not to.
While typing this I thought of perhaps using the video instead of capturing the images, but not sure this would help in any way.
Instead of a different approach to the way of capturing the image, I could try to only grab the image if I can confirm that the device is as close as still as possible (using a threshold value). Perhaps I could use the gyroscope for this (we are using it to check they have moved the device to a place and angle we consider useful for the process). The drawback of this is that I am not sure it would really mitigate our problem... how still is still enough? is it possible for the person to be that still for a second?
So my question here is, can anyone think of another alternative to those I descrived? or perhaps improve one of the enumerated ones?
BTW does anyone know what are Apple's plans for the ImageCapture API?
I am building an app with a spherical panorama photo with a jpg size about 4Mb. During development I am constantly refreshing the page I am working on to see changes, as well as opening multiple other three.js example pages to get tips. When Firefox first starts up, it uses around 250MB (I have a few tabs that open by default since it keeps crashing). When I refresh the page it jumps to around 420MB, then tapers slowly back down, but usually not to where it started from. If I refresh 2 times in 15 seconds or so, it will climb to nearly 500MB.
Usually I am not paying attention to my memory usage singe I have 32GB, but when firefox gets up around 2.5GB of memory used, along with around 15% processor usage, it starts bogging down and will crash. I would understand if my scene were particularly complicated, but it isn't, for the most part it is a single spherical pano, and one additional element I am working on at the time.
Is there something I should be adding to my code to clear out buffers between refreshes?
Seems this is a problem with TextGeometry without a solution.
https://github.com/mrdoob/three.js/issues/8478
I do have a Paper.path() in Raphael that is filled with a simple texture:
var fill = screen.path(Iso.topFacePath(top)).attr({
fill: 'url(http://www.example.com/mytexture.jpg)',
});
The path can be altered by the user via drag and drop. For this I use Element.drag() to bind the handlers.
The problem that I encouter now is that while the onmove-handler function is called the element in question will be recalculated and has to be drawn again. Apparently this is "too much" for raphael and the fill pattern will disappear randomly (flicker) and appear again some time later (at latest onend).
The actual code I use is a little too much to post here but I built a fiddle where you can see what's going on (you can drag the upper sides of the quadrangle).
Is there a simple fix to this?
I am used to canvas much more than raphael (actually this is the first time I really use raphael) so maybe my approach of redrawing everything everytime sth changes is plain wrong?
EDIT: I just found out that seems to be somehow browser-related as well. Chrome and Firefox will produce the flicker where Safari seems to do everything just fine.
This seems to be caching issue (raphael.js does not cache the bitmap fill and will reload it on every change) and is fixed (for me) by this pull request on GitHub that is (as of 08/14/2012) still pending.
Raphael is pretty hard / impossible to build oneself as the make file points to local and/or inexistent files, but you can either concatenate everything by hand, modify the build script or use the modified build that is used in the example to get hold of the fix.
Let's hope it will find its way into a future release of Raphael.
I have been working on an experiment to render HTML into a canvas image, by having javascript read all the necessary information from the loaded DOM. As canvas lacks many of the standard parts of CSS, especially when it comes to text formatting, a lot of work arounds and performance intense processes need to be done (letter-spacing for one). The intent is and never will be to make a fool proof HTML renderer, as it simply won't be possible, but instead try and make as accurate as it can be.
For the sample pages, Google Chrome usually loads them significantly faster than FF. However, for some pages (usually the bigger ones), Chrome completely freezes, where as Firefox loads them fine. Now, I have been trying to pinpoint where exactly things go haywire, but haven't had much luck as it doesn't end up outputting anything in Chrome.
Does Chrome have some limit of how many canvas draws can be performed within a certain time span, or how much system resources a page can use? How can I start untangling the bottleneck if I can't get any sort of feedback from the page at all (as it just hangs up)?
Examples (what it should do, is render a canvas image on top of the page, which should look more or less same than the actual HTML page. You can toggle the canvas image (show/hide) by clicking it. Please don't open them either if you got unsaved work in your browsers, as it may end up hanging them as well.):
simple test, works fine in FF/Chrome
another simple test, works fine in FF/Chrome
Complete page, works fine in FF/Chrome
Complete page, only works in FF < 4, Chrome freezes
They all use the same js which can be found here.
I am not looking for a blazing fast script, as with the type of emulation this renders the images, I don't think it could even be done. Simply trying to find ways to make it perhaps slightly more efficient, without losing any of its current functionality.
Where to begin?
Break it down.
Use the same example and cut how much you do it it (your rendering code) in half. Does it still not work? In half again, etc. Did it work? Put back half of what you took out.
As in, get rid of all attempted text rendering, or all border/padding code. Just comment it out. Does it work then?
Or try just commenting out ctx.drawImage(img,x,y); on line 199 and nothing else. Does it work then?
If you're lucky you'll be able to determine a critical point where Chrome is spending a lot of time doing something.
Have you tried using Chrome's built-in performance profiler?
The problem appeared to be with the css attribute background-repeat, and specifically repeat-x. Commenting out
for(bgx=(x+background_position_left);bgx<=w;){
drawImage(image,bgx,(y+background_position_top));
bgx = bgx+image.width;
}
Fixed the issue at least for chrome, and looking at that it most likely was an endless loop as Kinlan proposed, but why exactly it gets stuck only on newer versions of FF and chrome is something I'll need to look more in detail (most likely not having the image.width available yet, or something similar).