A speculative roadmap to the land of algorithmic textures
Algorithmic textures will become incorporated into browsers from two directions.
The first option is the hardcore long term solution. The second is useful in illustrating a method by which the first option may be attained.
- A texture backdrop file format for the web will come into being. This will not be a bit map, but instructions and guidelines about how to construct a bitmap to the client. The client will then be able to generate an image of an appropriate size.
- For browsers with low bandwidth connections there will be an option very similar to the
alt= parameter in <img> tags. This will be a more simple algorithmic texture generator. Using options specified in the <body> tag, it will be capable of generating an image in preference to loading a bitmap backdrop, and in the absence of a texture generation file. For text only browsers, this could even be translated into a description of the backdrop image, in the absence of any
As mentioned in the title of this page, it is possible to gain access to 16 million textures using only 3 bytes to specify each one. Surely this must be the ultimate in data compression of textures.
In practice it this option would be of limited practicality, but it certainly points the way to go.
Some may doubt the claims here that browsers will soon support algorithmic textures. However, these people are invited to consider the following:
All that is needed is a standard.
- Browsers can support algorithmic textures using simple existing technology, and remain compatable with the rest of the network.
- Pages which use algorithmic textures will have bitmaps as backups in case other browsers do not yet support algorithmic texture generation (similar to
- On browsers which do offer support, backgrounds will be available much faster, will be in 24 bit colour, and will not suffer from repetitive pattern problems.
- Algorithmic textures are perceived as being cool technology; once one browser supports them everyone will want them.
- Algorithmic textures can allow an easy implementation of letting different areas of the screen be different colours, textures, and shades. Crazy stunts like stretching textures to very long thin horizontal strips so that they provide an attractive left-hand edge to a table would no longer be required.
- Algorithmic textures can be simply animated, allowing for a more modern equivalent of the animated GIF backdrop, only with a tiny fraction of the download time. This feature alone, although it is very gimmicky, would be sufficient to sell people the idea of algorithmic textures.
Such a standard is not currently likely to come from the likes of W3C. As far
as the author is able to see, there is no current discussion of the matter
Though the standard would have to be a completely open one, the advantages of
being in the position of the developing company should be self-evident. Not
only would this contribute to a reputaion for innovative and cutting edge web
technology, but would also give a head start over the competition in the area,
and offer influence over the future evolution of the standard.
In a similar manner to the way in which script files are currently embedded
inside HTML documents, texture generation commands could be embedded into the
Concrete proposals about a vehicle to use to get there.
The HTML attributes to the <body> tag proposed are initially as follows:
A list of useful initial attributes could include:
- <body background=
back.jpg text=etc...> as normal;
- <body background=
back.alg text=etc...> using Algorithmic texture filetype standard instead of JPEG or GIF;
- <body ATType=
#10F03320 text=etc...> - embedded algorithmic texture.
ATType - Text description of the type of texture to be generated;
ATData="#xxyyzz" - Parameters for ATType - by using these two commands alone, great things could be achieved;
#RRGGBB - Foreground colour for simple textures.
#RRGGBB - Background colour for simple textures.
ATDim - Fractal dimension for fractal noise type textures.
The texture generation program would need to be written in a low level language (for best speed) and Java (for portability) at the very least.
A brief description of the interface of the texture generation plug-in with the browser follows (a more detailed description is here):
The browser asks for a texture to be generated from a referred-to HTML fragment.
For some light relief from these matters, readers are invited to peruse the
only other proposal concerning alternative web
textures the author has encountered.
- Colour depth (1-24 bit);
- Use existing palette option (if not 24 bit);
- What type of dithering to use (if not 24 bit);
- Width and Height. These would normally be -1. However, algorithmic textures can be easily made to tesselate, and at the browsers request, this should be an option. This may be due to the user wanting to speed up texture generation, or by the program running short of memory.
The technology to pefrom all the algorithmic texture generation described in this document is available now.
<IMG> tag proposals | <BODY> tag proposals | Background proposals | The browser | Acorn | Java | News