Memory management for panorama tour - memory

Building a tour of iPhone partial panoramas.
There are some 40+ of them and it seems as if memory is running out on mobile devices.
Also, using version A-frame 0.5.0, the code below works on desktop, but not in latest version 0.9.2.
<a-entity id="pano_01" visible="true">
<a-curvedimage asset-on-demand="src: ../Html_Templates/pix/Upgrade.jpg" height="145" radius="100" theta-length="300" rotation="0 33 0"></a-curvedimage>
<a-sky asset-on-demand="src: ../Html_Templates/pix/Upgrade_sky.jpg" rotation="0 -90 0"></a-sky>
<a-image asset-on-demand="src: ../Html_Templates/pix/UI_Next.png" position="0 -0.5 -3" scale="0.35 0.35 0.35" onclick="setpano_02()"></a-image>
</a-entity>
<a-entity id="pano_02" visible="false">
<a-sky asset-on-demand="src: ../Html_Templates/pix/JRO_Arrive_sky.jpg"></a-sky>
<a-curvedimage asset-on-demand="src: ../Html_Templates/pix/JRO_Arrive.jpg" height="140" radius="100.0" theta-length="300" rotation="0 60 0"></a-curvedimage>
<a-image asset-on-demand="src: ../Html_Templates/pix/UI_Next.png" position="1 -0.5 -3" scale="0.35 0.35 0.35" onclick="setpano_03()"></a-image>
<a-image asset-on-demand="src: ../Html_Templates/pix/UI_Back.png" position="-1 -0.5 -3" scale="0.35 0.35 0.35" onclick="setpano_01()"></a-image>
</a-entity>
Java that support the above:
function setpano_01() {
document.getElementById('pano_01').setAttribute('visible', 'true')
document.getElementById('pano_02').setAttribute('visible', 'false')
}
function setpano_02() {
document.getElementById('pano_01').setAttribute('visible', 'false')
document.getElementById('pano_02').setAttribute('visible', 'true')
document.getElementById('pano_03').setAttribute('visible', 'false')
My expectation is that the asset-on-demand script would help in releasing memory resources, but it seems it does not work for this strategy.
Also, I was hoping the latest version of A-Frame would have improved memory management.
(I hope the question is now better phrased).

There is a custom component called aframe-asset on demand.
https://www.npmjs.com/package/aframe-asset-on-demand-component
It dymanically loads images as assets and also removes them from memory.
This will probably solve your graphic memory problems.
"Remove Asset from Memory when not needed anymore. If you just remove the Texture from an entity, it will not be removed from entirely from THREE.JS and still use precious memory (precious especially on mobile). The A-Frame Asset OnDemand makes sure, that the Asset is removed in a way that free's up memory."
I found this by googling 'aframe dynamically load assets'

Related

client's cairo surfaces screenshots

I just discovered screenshots possibilities using client.content property.
So to test this functionnality, I put this code and bind it to the XF86Reload key :
awful.key({ }, "XF86Reload", function()
local i = 0
for c in awful.client.iterate(function() return true end)
do
local f = c.name
gears.surface(c.content):write_to_png( "/home/david/" .. string.format('%02i',i) .."-" .. f .. ".png")
i=i+1
end
end)
Unfortunately, some images are puzzled. Is the Cairo surface needs to be on the screen (ie non minimized) to be properly shot? (it seems it's also happening sometimes to visible windows) or maybe some other reason I can't see...
Is the Cairo surface needs to be on the screen (ie non minimized) to be properly shot?
Yes (and also: may not be obscured by other windows or outside of the visible space; you can only get what is actually shown on the display).
Also note that running Compton or another compositing manager makes it a lot more reliable

MetaEditor/MQL4 ExpertAdviser: Local Variable Declaration More Than Once?

I am looking at some old MetaEditor4 / MQL4 code, where a local variable was declared twice:
......
1 int start()
2 {
3 if (1==2)
4 {
5 double myVar = 1;
6 } else
7 {
8 double myVar = 2;
9 }
10 return;
11 }
.......
The compilation process in MetaEditor, version 5.00, build 1601, fails with:
'myVar' - variable already defined in line 8.
If I remove the line 8, the compilation goes well.
My questions are:
1. Is there any option in MetaEditor that tolerates the multiple declaration of a local variable?
2. In previous versions of MetaTrader Terminal 4 / MetaEditor and .MQ4 code: was it possible to declare a local variable more than once in such a situation?
3. The MetaEditor has the version 5.00, build 1601, but the extension of the code is .mq4 and it was installed together with the MetaTrader Terminal software MetaTrader4 ( from FXCM ). Therefore I assume I can still use .MQ4 code with it. Is there any chance to get a pure MQL4 installation from somewhere?
Whenever I install mt4 ( from e.g.: mt4 download), it ends up
with the mt5 installer.
Prologue:
The worlds of MQL4 evolve. One may try to circumvent this fact, but finally, at one's own disappointment, attempts to avoid evolution will sooner or later go in vain.
Having been thrown into a need to re-engineer code-base spanning a few man*decades in size, I can tell you many stories about what worked and what did not.
An "Old code" v/s a New-MQL4.56789
If just one thing ought be taken from this, never try to "circumvent" New-MQL4, but rather review the code and refactor the "Old code" - this is a way safer way to survive ( way longer ).
Yes, there are chances ( zero warrants, just a few chances left temporarily on the table ) the new compiler version will remain able to generate an executable version of the code, but given a new set of rules have already come in the city, the game will not last long.
Ad 1 + 2 )Compiler still tolerates multiple declarations, but not in one scope
If new version of a compiler defined that any variable is declared only relative to it's scope of validity, the serious programmer ought take this as a general principle. The code above actually has other problem, right nailed to the scope-of-validity:
2 ...
3 if ( 1 == 2 ) {
4 ...
5 double myVar = 1; // myVar declared & known |since HERE >
6 ... // masking any other,|known HERE :
7 ... // |known HERE :
8 } else // |till HERE . Undef further
9 {
10 ...
11 double myVar = 2; // myVar declared & known |since HERE >
12 // masking any other,|known HERE :
13 ... // |known HERE :
14 } // |till HERE . Undef further
so, if there were any _global_ scope'd variable with the same name myVar, it will not be "visible" during an existence of locally declared variable, wearing the same name.
Finally, having the code-execution escaped from any of the lines 8 or 14 further, the locally there declared variable double myVar simply ceased to exist anymore and this behaviour is principally correct ( and the "older" compiler releases were tolerating a sort of dangerous habit of side-effects, during years of tolerating scope-of-validity spillover(s), so it was the high time to clean the rules, so as to meet a fair level of C/S standards.
Ad 3) language receives a lot from MQL5, even if not used in MQL4
Yes, MetaEditor will correctly compile a MQL4 code into .mq4 code-execution format, no problem here. Even an auto-update process started to go independently from MT4 Terminal platform (auto-)updates ( so you will quite often see new Help file coming and enforced re-compilation of all your localhost visible .MQ4 assets into updated .EX4 format, so "Do not panic."
Better never install a Broker-agnostic MT4, always go to your Broker's Support and get installation package & help from your Broker. This is business relation you have signed in a contract, so keep these strings as you are going to trade your money on a table they operate under the set Terms & Conditions. Some Brokers have means of platform customisations, so rather benefit from their custom settings that will match their Server-side automation.
It is more a question of economy of R&D efforts. ( May read a lot about language components injected from the MQL5 domain in the IDE Editor MQL4 Help ). This is a natural will of the product design strategy, not to double efforts on a dual-line. Without doubts, there are many details the Help file could be improved and better maintained, the common sense here is to live with the facts and re-learn what newly introduced features remain neutral for the MQL4 code base and what new things may actually help one a lot in aspects, where older compilers were short in powers.
If one objects that some compiler / platform re-design steps were bad, I would agree on a single-thread, platform-critical, potentially blocking, concentration of executing all the CustomIndicator-s in just one SPoF-thread.
But C'est La Vie, until system architects will not review this SPoF, the platform will remain susceptible to crashes from this feature, but the ball is on the other side of the court and a change will have to be implemented there.
the code might be run with 'strict' or non-strict mode.
strict means that variable must be declared within its scope, non-strict - all the mess that you have now.
so put #property strict at the beginning of the file
open a demo account somewhere and install mt4 there. demo can be valid for 30 days only with registration via web-site of a broker or with unlimited and demo opened from mt4 (example - Alpari)

large object area of the tenure space consistently 100%

Is it an issue if "loa" is consisting 100%? There free memory in other areas. If it is an in issue what is the proper solution? gc type="scavenge"
<mem type="loa" free="*******" total="*******" percent="100" />
<gc-end id="xxxx" type="scavenge" contextid="xxxx" durationms="34.230"
<mem-info id="xxx" free="" total="" percent="72">
<mem type="nursery" free="" total="" percent="98" />
<mem type="tenure" free="" total="" percent="64">
<mem type="soa" free="" total="" percent="63" />
JVM details
java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxp6460_26sr8fp4ifix-20150514_01(SR8 FP4+IX90162+IV73188))
IBM J9 VM (build 2.6, JRE 1.6.0 Linux ppc64-64 Compressed References 20150512_248381 (JIT enabled, AOT enabled)
J9VM - R26_Java626_SR8_20150512_1623_B248381
JIT - tr.r11_20150401_88894
GC - R26_Java626_SR8_20150512_1623_B248381_CMPRSS
J9CL - 20150512_248381)
JCL - 20150413_01
LOA is the Large Object Area memory type used to satisfy the large object allocation requests, which could not be satisfied in Small Object Area of tenure heap space. If the application does not allocate large objects, the LOA will continue to show 100% free in verbose gc log for few GC cycles. This is not a problem as such because GC algorithm takes care of monitoring LOA usage every gc cycle and shrinks it after few number of GC cycles in case if it is not used consistently.
For more details on command-line options to configure LOA size, please refer:
https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.0.0/com.ibm.java.lnx.70.doc/diag/understanding/mm_allocation_loa.html

ColdFusion RequestTimeout in component ignored or ineffective

We have several repos where individual pages (eg. scheduled maintenance operations) need to be allowed to execute longer requests (eg. 5 minutes).
However in one repo, setting requesttimeout to 360 seems completely ineffectual! No matter what we set this value to it timesout at 60.
<cfcomponent>
<cfsetting requesttimeout="360" />
<cffunction
name="doit"
access="public"
returntype="string"
output="true" >
<cfinclude template="arrComs.inc.cfm">
<cfset strHTMLReport = '<ul>'>
<cfloop array="#arrComs#" index="i">
<cfscript>
thisCom = CreateObject( 'component', i.fileSansExt );
skvResult = thisCom.generate();
// Sleep for 5 seconds to give MySQL a bit of breathing space
sleep( 3000 );
</cfscript>
<cfset strHTMLReport &= '<li>' & skvResult.msg & '</li>'>
</cfloop>
<cfset strHTMLReport &= '</ul>'>
<cfreturn strHTMLReport>
</cffunction>
</cfcomponent>
Any ideas? Where can I look to help diagnose this? How many locations can requesttimeout be set and why does it seem repo specific?
SOLVED: Deleted the same 1 line of code from 2 of the components that were called inside the loop. The lines set the RequestTimeout to 60, thus overriding the timeout set in the parent.
Humble Pie Time: My mistake was to forget that the components that are called inside the loop also have a line of code with sets the timeout to 60 seconds. Although the error was reporting a timeout it was not clear exactly where. In hindsight I should have searched my code base for the number 60 and I would have found the 2 offending lines a lot sooner.
Further thinking, whilst researching this I found that CFLOOP and CFQUERY both have timeout limits which can be set so for thoroughness I also increased the timeouts on the MySQL queries in the component.
Further further thinking, components that were called earlier in the loop changed the requesttimeout for components that were called later. So although I was diagnosing by inspecting the parent function and the function that it timedout on, I was not given any reason to suspect the components that were called previously in the process.

jquery-1.5.1.min.js and IE8

IE8 gives an error from jquery 1.5.1 minimized: Invalid argument, but firefox doesn't.
The error comes from this line:w
a.elem.style&&a.elem.style[a.prop]!=null?a.elem.style[a.prop]=(a.prop==="width"||a.prop==="height"?Math.max(0,a.now):a.now)+a.unit:a.elem[a.prop]=a.now}}}),d.expr&&d.expr.filters&&(d.expr.filters.animated=function(a){return d.grep(d.timers,function(b){return a===b.elem}).length});var ce=/^t(?:able|d|h)$/i,cf=/^(?:body|html)$/i;"getBoundingClientRect"in c.documentElement?d.fn.offset=function(a){var b=this[0],c;if(a)return this.each(function(b){d.offset.setOffset(this,a,b)});if(!b||!b.ownerDocument)return null;if(b===b.ownerDocument.body)return d.offset.bodyOffset(b);try{c=b.getBoundingClientRect()}catch(e){}var f=b.ownerDocument,g=f.documentElement;if(!c||!d.contains(g,b))return c?{top:c.top,left:c.left}:{top:0,left:0};var h=f.body,i=cg(f),j=g.clientTop||h.clientTop||0,k=g.clientLeft||h.clientLeft||0,l=i.pageYOffset||d.support.boxModel&&g.scrollTop||h.scrollTop,m=i.pageXOffset||d.support.boxModel&&g.scrollLeft||h.scrollLeft,n=c.top+l-j,o=c.left+m-k;return{top:n,left:o}}:d.fn.offset=function(a){var b=this[0];if(a)return this.each(function(b){d.offset.setOffset(this,a,b)});if(!b||!b.ownerDocument)return null;if(b===b.ownerDocument.body)return d.offset.bodyOffset(b);d.offset.initialize();var c,e=b.offsetParent,f=b,g=b.ownerDocument,h=g.documentElement,i=g.body,j=g.defaultView,k=j?j.getComputedStyle(b,null):b.currentStyle,l=b.offsetTop,m=b.offsetLeft;while((b=b.parentNode)&&b!==i&&b!==h){if(d.offset.supportsFixedPosition&&k.position==="fixed")break;c=j?j.getComputedStyle(b,null):b.currentStyle,l-=b.scrollTop,m-=b.scrollLeft,b===e&&(l+=b.offsetTop,m+=b.offsetLeft,d.offset.doesNotAddBorder&&(!d.offset.doesAddBorderForTableAndCells||!ce.test(b.nodeName))&&(l+=parseFloat(c.borderTopWidth)||0,m+=parseFloat(c.borderLeftWidth)||0),f=e,e=b.offsetParent),d.offset.subtractsBorderForOverflowNotVisible&&c.overflow!=="visible"&&(l+=parseFloat(c.borderTopWidth)||0,m+=parseFloat(c.borderLeftWidth)||0),k=c}if(k.position==="relative"||k.position==="static")l+=i.offsetTop,m+=i.offsetLeft;d.offset.supportsFixedPosition&&k.position==="fixed"&&(l+=Math.max(h.scrollTop,i.scrollTop),m+=Math.max(h.scrollLeft,i.scrollLeft));return{top:l,left:m}},d.offset={initialize:function(){var a=c.body,b=c.createElement("div"),e,f,g,h,i=parseFloat(d.css(a,"marginTop"))||0,j="<div style='position:absolute;top:0;left:0;margin:0;border:5px solid #000;padding:0;width:1px;height:1px;'><div></div></div><table style='position:absolute;top:0;left:0;margin:0;border:5px solid #000;padding:0;width:1px;height:1px;' cellpadding='0' cellspacing='0'><tr><td></td></tr></table>";d.extend(b.style,{position:"absolute",top:0,left:0,margin:0,border:0,width:"1px",height:"1px",visibility:"hidden"}),b.innerHTML=j,a.insertBefore(b,a.firstChild),e=b.firstChild,f=e.firstChild,h=e.nextSibling.firstChild.firstChild,this.doesNotAddBorder=f.offsetTop!==5,this.doesAddBorderForTableAndCells=h.offsetTop===5,f.style.position="fixed",f.style.top="20px",this.supportsFixedPosition=f.offsetTop===20||f.offsetTop===15,f.style.position=f.style.top="",e.style.overflow="hidden",e.style.position="relative",this.subtractsBorderForOverflowNotVisible=f.offsetTop===-5,this.doesNotIncludeMarginInBodyOffset=a.offsetTop!==i,a.removeChild(b),a=b=e=f=g=h=null,d.offset.initialize=d.noop},bodyOffset:function(a){var b=a.offsetTop,c=a.offsetLeft;d.offset.initialize(),d.offset.doesNotIncludeMarginInBodyOffset&&(b+=parseFloat(d.css(a,"marginTop"))||0,c+=parseFloat(d.css(a,"marginLeft"))||0);return{top:b,left:c}},setOffset:function(a,b,c){var e=d.css(a,"position");e==="static"&&(a.style.position="relative");var f=d(a),g=f.offset(),h=d.css(a,"top"),i=d.css(a,"left"),j=e==="absolute"&&d.inArray("auto",[h,i])>-1,k={},l={},m,n;j&&(l=f.position()),m=j?l.top:parseInt(h,10)||0,n=j?l.left:parseInt(i,10)||0,d.isFunction(b)&&(b=b.call(a,c,g)),b.top!=null&&(k.top=b.top-g.top+m),b.left!=null&&(k.left=b.left-g.left+n),"using"in b?b.using.call(a,k):f.css(k)}},d.fn.extend({position:function(){if(!this[0])return null;var a=this[0],b=this.offsetParent(),c=this.offset(),e=cf.test(b[0].nodeName)?{top:0,left:0}:b.offset();c.top-=parseFloat(d.css(a,"marginTop"))||0,c.left-=parseFloat(d.css(a,"marginLeft"))||0,e.top+=parseFloat(d.css(b[0],"borderTopWidth"))||0,e.left+=parseFloat(d.css(b[0],"borderLeftWidth"))||0;return{top:c.top-e.top,left:c.left-e.left}},offsetParent:function(){return this.map(function(){var a=this.offsetParent||c.body;while(a&&(!cf.test(a.nodeName)&&d.css(a,"position")==="static"))a=a.offsetParent;return a})}}),d.each(["Left","Top"],function(a,c){var e="scroll"+c;d.fn[e]=function(c){var f=this[0],g;if(!f)return null;if(c!==b)return this.each(function(){g=cg(this),g?g.scrollTo(a?d(g).scrollLeft():c,a?c:d(g).scrollTop()):this[e]=c});g=cg(f);return g?"pageXOffset"in g?g[a?"pageYOffset":"pageXOffset"]:d.support.boxModel&&g.document.documentElement[e]||g.document.body[e]:f[e]}}),d.each(["Height","Width"],function(a,c){var e=c.toLowerCase();d.fn["inner"+c]=function(){return this[0]?parseFloat(d.css(this[0],e,"padding")):null},d.fn["outer"+c]=function(a){return this[0]?parseFloat(d.css(this[0],e,a?"margin":"border")):null},d.fn[e]=function(a){var f=this[0];if(!f)return a==null?null:this;if(d.isFunction(a))return this.each(function(b){var c=d(this);c[e](a.call(this,b,c[e]()))});if(d.isWindow(f)){var g=f.document.documentElement["client"+c];return f.document.compatMode==="CSS1Compat"&&g||f.document.body["client"+c]||g}if(f.nodeType===9)return Math.max(f.documentElement["client"+c],f.body["scroll"+c],f.documentElement["scroll"+c],f.body["offset"+c],f.documentElement["offset"+c]);if(a===b){var h=d.css(f,e),i=parseFloat(h);return d.isNaN(i)?h:i}return this.css(e,typeof a==="string"?a:a+"px")}}),a.jQuery=a.$=d})(window)
My code doesn't have an error...
I suggest that you debug your code, as the min version of jquery works just fine. You have a problem with your code that is indirectly causing an error in internet explorer and you have to do a work around.
My favorite thing (and what I did for a similar problem that I just figured out) is to
cut out all your javascript and run it to make sure that it works
paste it back in, a chunk at a time, testing each time
once you find the offending chunk of javascript code, cut that out and put everything else back in to make sure that is the only problem
narrow it down in that chunk to see where internet explorer is being retarded. If you are using PHP, you might need to do something like this to have internet explorer skip the code that is causing it to fail
$('li[title]').qtip({
style: {
name: 'dark',
background: $('.ui-widget-header:first').css('background-color')
<?php
//internet explorer is retarded
if(!preg_match('/MSIE/i',$_SERVER["HTTP_USER_AGENT"]))
{
echo ", tip: true";
}
?>
},
position: {
target: 'mouse',
corner: {
target: 'topLeft',
tooltip: 'bottomLeft'
}
}
});
I hope that helps! (If it did, please mark as answer)
I used the "slideToggle" from jquery version "jquery-1.6.4.min.js" on one big DIV element.
The "DIV" element has inside more html elements.
In internet explorer 8 (maybe on FF too) when I try to load the slideToggle function on this big DIV I received an error. Not sure what was the real cause of error but during my investigation I found a bug into the jquery:
_default:function(a){a.elem.style&&a.elem.style[a.prop]!=null?a.elem.style[a.prop]=(a.prop==="width"||a.prop==="height"?Math.max(0,a.now):a.now)+a.unit:a.elem[a.prop]=a.now}}})
There are situations when "a" variable is "NAN". Because of this I got some errors.
So I placed this check routine inside:
if(isNaN(a.now)){return;}
And all my problems gone.
_default:function(a){if(isNaN(a.now)){return;}a.elem.style&&a.elem.style[a.prop]!=null?a.elem.style[a.prop]=(a.prop==="width"||a.prop==="height"?Math.max(0,a.now):a.now)+a.unit:a.elem[a.prop]=a.now}}})
For me, this comes up when setting the padding or margins to a negative number. This has been discussed in a number of places online re: "IE negative padding". The following are the watch values from my IE console that prove this.
a.prop >> 'paddingTop'
a.prop==="width"||a.prop==="height" >> false
Math.max(0,a.now) >> 0
a.now >> -1.8277004484618357
(a.prop==="width"||a.prop==="height"?Math.max(0,a.now):a.now)+a.unit >> "-1.8277004484618357px"
a.elem.style[a.prop]=(a.prop==="width"||a.prop==="height"?Math.max(0,a.now):a.now)+a.unit >> Invalid Argument
experimenting:
- a.elem.style[a.prop] = '1px' >> '1px'
- a.elem.style[a.prop] = '-1px' >> Invalid Argument
The thread over at: StackOverflow: jQuery, IE & Animate proposes the following:
a.elem.style[a.prop]=(a.prop==="width"||a.prop==="height"?Math.max(0,a.now||0):a.now)+a.unit;
... which did nothing for me.
I don't really think this is a jQuery bug, and I haven't found it in their bug tracking system (I'll admit I haven't looked too hard), but rather an issue with IE not being able to handle negative padding/margins. It's a tough call whether jQuery should handle this or not ...
EDIT: This was opened as jQuery bug 4571, where they decided that the behavior was correct and that developers should be more careful in setting margins/padding values since a negative margin/pad really isn't valid. They went on to say that they wish FF would throw an error like IE. Wow! don't hear that often!

Resources