Sporadic bad widths for TextFields in HTML5 viewer.

  • I am witnessing the sporadic failure of TextFields to render properly in the HTML5 viewer. I am using the latest 1.16.3 version and am testing using OS X Mountain Loin, with up-to-date versions of Chrome, Firefox, and Safari. The sporadic failures are taking place in testing on all three browsers.

    When they fail, the TextFields do not use the width property that is defined for them - they instead use the default width of 400px. All of the textFields defined in my XML have explicit withs defined on them, i.e.


    <hotspot style="infotext" autoheight="true" align="leftbottom" edge="leftbottom" width="90" html="Apollo Temple" atv="3.2950" ath="-77.567" />

    The "infotext" style is defined as follows:


    <style name="infotext"
    url="textfield.swf"
    visible="false"
    children="false"
    css="text-align:center; color:#FFFFFF; font-family:Arial"
    autoheight="true"
    vcenter="false"
    background="true"
    backgroundcolor="0x000000"
    backgroundalpha="0.4"
    border="true"
    bordercolor="0xFFFFFF"
    borderalpha="1.0"
    borderwidth="1.0"
    roundedge="0"
    shadow="3.0"
    shadowrange="4.0"
    shadowangle="45"
    shadowcolor="0x000000"
    shadowalpha="1.0"
    textshadow="0.0"
    textshadowrange="4.0"
    textshadowangle="45"
    textshadowcolor="0x000000"
    textshadowalpha="1.0"
    onautosized=""
    handcursor="false"
    />

    The failures seem to be quite haphazard - the panos render properly about 90 percent of the time. And the failures do not seem to be associated with particular panoramas - sometimes a particular panorama will render correctly, sometimes not. When the failure does take place, it usually is only for a portion of the TextFields within the panorama, with all the incorrectly rendered TextFields in a continuous pan range with no intermingled correctly rendered TextFields. Note that the TextFields are not defined in order by pan in the xml file, so I don't think the set of TextFields that fail is associated with their order in the xml file.

    I have attached a screen shot of what the failure looks like.

    So is anyone else seeing this, and maybe have a workaround? Any hope for a fix, Klaus? It really, really smells like some kind of race condition, but tracing within my code did not provide any insights, so I have to suspect that it is deeper within the KRPano code itself.

    Cheers,
    Larry Wieland

  • Hi Klaus. I suspect that after sleeping on it I know what's going on and I'm going to try some changes. I have an action method to load a new panorama as follows:

    <action name="loadNewNode"> <!-- %1 = node ID, %2 = scene id-->
    loadpano(%HTMLPATH%/krpano-nodes/%1.xml);
    loadscene(%2,null,MERGE,NOBLEND);
    </action>

    and I'm guessing that there is a race condition between the completion of the loadpano command and the execution of the loadscene command. I am going to restructure the code to save the scene id in a variable, and then execute the loadscene command, using the saved scene id, as part of an action triggered by onstart, and hopefully that should resolve it. I'll post the results.

    The general architecture that I am using is that I have one xml file that I load at startup of the application defining global actions and hotspot styles, but does not contain any panoramas. I then work through your Javascript interface to load individual 'nodes' into KRPano, where a node consists of one or more versions of a scene shot at the same general application. The loadNewNode action you see above is called though the Javascript interface when the application loads the starting node or the user moves to a new location. Once at a location, if a node contains more than one scene, the user has the ability through my interface to switch from scene to scene, in which case I again call an action through the Javascript interface which just executes a loadscene without having to do a loadpano.

    If you are interested in looking at the app, which is still definitely pre-beta, you can go to http://gcpano.org/boilerplate/boilerplate.html. The specific code where I am seeing the error, however, has not yet been uploaded. If the issue persists following the changes I plan to make, I'll get it uploaded and give you specific instructions on how to replicate it.

    Incidentally, in my attempt to debug I did a fair amount of tracing, trying to figure out if I needed to wait for the onxmlcomplete and/or onnewpano events. The documentation does not make it clear, at least to me, exactly what the relationship between these events is. I did witness that, at least in my testing, that onnewpano always gets fired after onxmlcomplete and that they always come in pairs. And what really surprised my was that calling loadscene by itself results in firing of both an onxmlcomplete and onnewpano event! My presumption was that onxmlcomplete would be fired only when loading a new xml file, and not when just loading a scene from within an xml file that was already loaded. So just what does the onxmlcomplete event represent? Does it mean that you have completed parsing and loading xml for a scene, whether it has just been loaded from a new xml file or not? And what sort of use cases would you respond to the onxmlcomplete event vs the onnewpano event, or is there really any use for these events that isn't covered by simply responding to the onstart event?

    Cheers,
    Larry

  • The problem is fixed, and it appears that the root cause was indeed calling loadscene immediately following loadpano in the same block of action code. Frankly I'm surprised that the scene would load at all given my original code, but race conditions can cause very strange things to take place *smile* . I re-architected my javascript code to listen for the KRPano onxmlcomplete event through the interface:

    1) I call KRPano.loadpano to load the XML file for the next node to be visited, but do not load a scene within the xml file.
    2) In response to the onxmlcomplete event triggered by loadpano, I call loadscene for the first scene to be displayed for the node.
    3) I ignore the onxmlcomplete event triggered by loadscene.
    4) I make additional calls to loadscene to change the scene as needed within the node, again ignoring the onxmlcomplete event.
    5) When its time to move to a new node, it's back to step 1).

    Cheers,
    Larry Wieland

  • Well I thought it was fixed, but it wasn't. There was another piece of the puzzle: after loading the first scene for a node, I was also then following up with a lookat and zoomto command. In my previous fix I had not yet put the lookat and zoomto code back in place, but when I did the original issue of sporadic bad widths for textfields was happening again. I then tweaked my solution to listen for the onnewpano events instead of onxmlcomplete events and now (hopefully *blink* ) the issue is fully resolved. Revised flow call:

    1) I call KRPano.loadpano to load the XML file for the next node to be visited, but do not load a scene within the xml file.
    2) Ignore the onxmlcomplete event triggered by loadpano.
    3) In response to the onnewpano event triggered by loadpano, I call
    loadscene for the first scene to be displayed for the node, but do not attempt to set its orientation
    4) Ignore the onxmlcomplete event triggered by loadscene.
    5) In response to the onnewpano event triggered by loadscene, call
    lookat and zoomto to set the initial orientation for the start scene
    6) I make additional calls to loadscene to change the scene as needed within the node, again ignoring the onxmlcomplete event, but setting the orientation as needed in response to the onnewpano event
    7) When its time to move to a new node, it's back to step 1).

    Cheers,
    Larry Wieland

  • Hi,

    the loadpano, loadscene calls or any of the events should not be related to the textfield widths...

    How or when where the hotspots added or defined?
    I'm unfortunately still not able to find any way that would reproduce wrong widths...

    Best regards,
    Klaus

  • Hi Klaus,

    The hotspots are defined directly in the xml file for the node, with the width declared explicitly for each hotspot. An xml file for one node is attached. The xml for each node is generated, but not through your development tool - I am using a tool that I have developed myself and is customized to the idiosyncrasies of my application. I am also attaching my startup.xml file, loaded once at startup time before any nodes are loaded. I also attempted to upload a javascript file, krpanointerface.js, which handles the direct communication between my application and KRPano, but alas your forum software does not allow the upload of a .js file. There is much, much more going on - the application has a complicated MVC architecture. Just suffice to say that all of the interface you see other than the panorama itself is in Javascript, and the map portion of the application, using Leaflet, is isolated from the panorama with communication taking place though the overall application MVC structure.

    I will also note that in my testing following my latest fix I did see the bad widths appear once and only once, and have been unable to reproduce it myself since, so though it seems that the issue has been mostly resolved, it does seem to still be lurking out there.

    I have uploaded my current codebase to the web, which you can access at http://gcpano.org/boilerplate/boilerplate.html. but as I just noted I can't reproduce the issue at this time myself at this time.

    Cheers,
    Larry Wieland

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!