The browser interface

The interface between the texture generation plug-in and the browser is specified as follows: the browser asks for a texture to be generated from a referred-to HTML fragment.

It also specifies:

• Colour depth (1-24 bit);
• Optionally, use a specified palette (not relevant at 24 bpp);
• Optionally what type of dithering to use (not relevant at 24 bpp);
• The width and height of the required image.

  In order to integrate seamlessly with existing browsers, width and height parameters can be fed to the texture generator, and it will then generate a texture that will seamlessly tesselate. The browser can then tile this just as it would any other background image.

• The textures generated have to tesselate seamlessly whilst being able to be generated at any specified size and scale. The second requirement is referred to as size invariance, and a texture generation language which supports this is said to generate size invariant textures. The size at which the texture would be generated would depend on a number of environmental variables determined by the browser or requested by the user. Relevant factors would include available memory, and processor speed (large textures take longer to create).

  This is of use when the browser is running in a low memory environment. It is noted here that when dealing with web pages, normally there will be some memory available for the texture generator to use as workspace, as a new document is about to be downloaded and rendered.

  As an option, a feature to enable backdrops without finite dimensions to be generated may be included. The browser would then ask for a rectangular area of this image and be fed back an image of the appropriate size. Naturally, implementing this option this requires some minor work to be done on the browser side.

• How many centi-seconds to wait before abandoning. One of the many positive features of algorithmic textures is that they can be generated very rapidly, before any text is displayed. In order to implement this feature, the browser should:
  • Set this time to a very short interval, and call the texture generation routine, passing it information from the relevant body attributes.
  • If the generater returns a texture, then the browser renders it and continues.
  • Otherwise the page should be rendered and the background displayed last, as normal. This activity should be done in the background, using either pre-emptive multi-tasking, or some lind of polling loop; the exact details depend on the operating system.

  The texture generation language is executed inside a virtual machine and so cannot crash or be used to propagate viruses.

  However, as any language of reasonable power may contain loops, and these may be nested and of variable sizes, generation of some textures may fail to terminate. This could happen if a corrupted texture arrived, or (if textures contain encrypted checksums, as is recommended), if a deliberately broken texture is generated.

  Although it is not in principle possible to determine whether an arbitrary program in any reasonably powerful language will terminate on inspection, the time to wait before abandoning can safely be set to be infinite. The texture generator then keeps tryng to make the image, until it is asked to stop by the browser when the user goes to another page.

• An image identification token.

  In any reasonable multi-tasking environment, it should be possible for more than one background to be being decoded at any moment.

  The texture generator passes the token back with the generated image, to enable the browser to identify it.

Other messages may also be implemented. For example, the size of the generated texture could be negotiated between the browser and the texture generator, depending on the quantity of memory the generator claims a given texture requires and how long it thinks it will take it to generate the image.