Re: Raising the issue of multi-threading


Hi Alexander,

--Original Message--:
>Hi!
>
>I'd like to raise the issue of multi-threading and the SVG-Spec. I really
>think that the spec should take multi-threaded environments into strong
>consideration. For example, let's take this:

Choosing to use multi-threading is an implementation detail.

The spec defines the semantics of what should happen, not how
an implementation should be architected. For example, there is
no definition of anti-aliasing requirements at all in the spec.
and that is deliberate. The effects of multi-threading fall into
the same category.

>var rect = document.createElementNS(.., "rect");
>rect.setAttributeNS(..)
>..
>document.rootElement.appendChild(rect);
>var theBBox = rect.getBbox();

It is fairly clear that the result of the getBbox call should
return the extent of the rect element - there is no
ambiguity here. The element is in the tree, so its bounds
can be computed.

>The last line in Renesis may contain garbage at this point. Why? Because the
>bbox (and other things like screen TM, client TM etc.) are calculated during
>the rendering step. But because Renesis v3 does multi-threaded rendering,
>you will never ever get a guarantee when those changes will make it to the
>rendering. The only possible solution I could think about is to introduce
>some kind of rendering feedback including cookies. Consider this:

The return value from getBbox should never depend on completion
of some asynchronous operation. The spec is clear about what
gets returned. If behind the scenes threads are used to retrieve
the correct result, then the implementation should guarantee that
it does so.

>var rect = document.createElementNS(.., "rect");
>rect.setAttributeNS(..)
>..
>document.rootElement.appendChild(rect);
>document.setRenderingCookie(123);
>
>Now you could wait for the appropriate callback:
>
>function renderComplete(evt, cookie)
>{
>  if (cookie == 123) { this is the pass we want }
>}

An interesting suggestion, but very implementation specific. It
assumes that all implementations rely on the render pass to generate
bound box information, which simply isn't the case.

For example, hit-testing can require calculation of bound boxes.
In the case where an implementation doesn't buffer the bound
boxes, this is probably required.

So the 'rendering cookie' idea is tied to one implementation
approach and is an attempt to work around a problem that is
specific to one architectural approach for a multi-threaded
implementation.

This problem isn't caused by multi-threading itself - but the
architecture that requires a render pass to generate bound
boxes - there are other approaches that will work in a multi-
threaded design.

>I think, multi-threaded environments become more and more important
>especially in the times of Multi-Core processors so we should give it a
>strong consideration. But for now, what are we actually supposed to do in
>Renesis for the previously described behaviour / issue? 

I agree multi-threaded environments are becoming more important
but the semantics of the spec are quite clear. The behaviour
in the spec is also something authors can rely on without
needing to concern themselves with what sort of implementation
is being targeted.

In your case, you have 2 options:
1) block at the getBbox call until the render pass is complete; or
2) walk the tree to generate the bound box if the render thread
   hasn't finished yet.

Best regards,
Alex

>mfG / Regards,
>Alexander Adam
>--
>Geschäftsführer / CEO
> 
>examotion GmbH
>Ostendstraße 115
>90482 Nürnberg, Germany
>
>Fon: +49 911 - 504901-11
>Fax: +49 911 - 504901-20
> 
>E-Mail: alexander.adam@examotion.com
>Web: http://www.examotion.com
> 
>Geschäftsführer: Alexander Adam
>Amtsgericht Nürnberg HRB Nr.: 23803
>Gerichtsstandort: Nürnberg
> 
>
>--------------------------------------------------
>LEGAL DISCLAIMER: The information in this email is confidential and may be
>legally privileged. It is intended solely for the addressee. Access to this
>email by anyone else is unauthorized. If you are not the intended recipient,
>any disclosure, copying, distribution or any action taken or omitted to be
>taken in reliance on it, is prohibited and may be unlawful.
>--------------------------------------------------
>
>
>
>
>
>
>

Received on Monday, 30 March 2009 11:04:42 UTC