[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [www-vrml] Re: [Vrspace-dev] Cortona createVrmlFromURL bug test code
- To: www-vrml <www-vrml@web3d.org>
- Subject: Re: [www-vrml] Re: [Vrspace-dev] Cortona createVrmlFromURL bug test code
- From: Braden McDaniel <braden@endoframe.com>
- Date: Fri, 25 Mar 2005 18:54:57 -0500
- Cc: vrspace-dev@lists.sourceforge.net
- In-reply-to: <42446C86.1060604@vrspace.org>
- References: <857841337.20050124102928@mail.ru> <41F5174D.5010906@vrspace.org> <1192788733.20050125003358@mail.ru> <41F5572C.3050109@vrspace.org> <52356044.20050203235911@mail.ru> <4203948A.8080506@vrspace.org> <1408542019.20050204220658@mail.ru> <4203A323.7000908@vrspace.org> <735889328.20050206010902@mail.ru> <42078E0E.6040703@vrspace.org> <85332644.20050218103551@mail.ru> <42160C49.3030900@vrspace.org> <6.0.3.0.0.20050319094226.01b3e288@mail.vrspace.org> <6.0.3.0.0.20050319103100.01cfac30@mail.vrspace.org> <6.0.3.0.0.20050319165807.01c98478@mail.vrspace.org> <001d01c52cd8$a80fe820$5530f845@lpaxtn01.pa.comcast.net> <6.0.3.0.0.20050319192328.01cbb580@mail.vrspace.org> <001f01c52d31$ede0b060$5530f845@lpaxtn01.pa.comcast.net> <6.0.3.0.0.20050320111633.01d077b0@mail.vrspace.org> <Pine.LNX.4.62.0503201827320.7915@www.cyworx.com> <6.0.3.0.0.20050310173713.01cafe40@mail.vrspace.org> <42446C86.1060604@vrspace.org>
- Sender: owner-www-vrml@web3d.org
On Fri, 2005-03-25 at 20:54 +0100, Josip Almasi wrote:
> Hi all,
>
> crosspost, browser bugs.
Well, tough call. Aren't you referring to an interface that was never
formally standardized (Marrin EAI)?
> Rob Meyers wrote:
> > This fact that event doesn’t raise for every assignment to addChildren
> > in boundaries of one frame (?) is not standards violation.
> > >>> , , createVrmlFromUrl, callback .
> > Scarcely it can disturb program’s logic if we take into account that
> > processing time for createVrmlFromUrl, and calling rules for callback
> > are not hardly defined.
> > >>> ,
> > With respect.
> > >>>
> > ParallelGraphics
> > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> >
> > Hah, hah, hah, well you see, since the standard is vague we decided to
> > choose a retarded method of implementing it, so therefore, its not a bug,
> > its a feature!!! No competent software designer would consider random
> > callbacks to an asynchronous api call acceptable. Come on now...
>
> Right, guess they had trouble implementing event model (thread safe) in C...
> ... OK so now we know it's broken and ParallelGraphics has no intentions
> to correct it. Just let's tell it to www-vrml so everybody else knows...
>
> FTR:
> --------------------
> <Quote>
> Alright, this is test code that exposes the issue. As Josip pointed
> out in that post you mentioned, the issue with Cortona is that it isn't
> thread safe in the sense that we have two threads, the java program, and
> Cortona itself. The API can't properly handle when its
> createVrmlFromURL method is called while it is already handling a call
> from before. I tried running synchronously, ie. make a call to
> createVrml..., wait for callback, then call again, etc... Here it
> properly handles the calls. We can't do this with VRS, it would take
> forever to load a world this way. The code I have attached is pretty
> self explanatory. Just double click test.html and the applet will
> attempt to load up a file from across the net many times. Check out the
> Java Console for the results of the test. You will see that Contact
> correctly calls the Callback function for each vrml file created, but
> Cortona skips calls. The applet tag has parameters you can play with
> such as sleepTime between calls, numberCalls, and the url of the
> vrmlfile to load.
> </Quote>
>
> I posted the code at http://www.vrspace.org/downloads/CortonaTest.zip .
404.
> Incidentally, I did notice another bug, but in Contact. It seems
> that Contact doesn't always call the callback function after processing
> a removeChildren event. On the other hand, Cortona seems to do this
> correctly.
Absent the code, let me see if I understand this...
So the callback is supposed to happen once the resource has been loaded;
but you're calling createVrmlFromURL frequently enough that it hasn't
finished loading one resource before you request another. And in this
case Cortona effectively interrupts loading of the previously requested
resource; the field value of the destination node (effectively) never
changes; and so you never get your callback.
I don't have a copy of the Marrin EAI spec handy; but here's what the
VRML97 spec says about Browser.createVrmlFromURL (4.12.10.10):
The createVrmlFromURL() instructs the browser to load a VRML
scene description from the given URL or URLs. The VRML file
referred to shall be self-contained (i.e., USE statements inside
the string may refer only to nodes DEF'ed in the string, and
non-built-in node types used by the string shall be prototyped
using EXTERNPROTO or PROTO statements inside the string). After
the scene is loaded, event is sent to the passed node returning
the root nodes of the corresponding VRML scene. The event
parameter contains a string naming an MFNode eventIn on the
passed node.
If the callback is supposed to happen "after the scene is loaded" and
the scene is never loaded, presumably the callback would never happen.
So Cortona's behavior strikes me as reasonable.
Perhaps you should be structuring your code only to make a subsequent
call to createVrmlFromURL after getting the callback from a previous
one.
--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>
-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html