Amiga', 'Aweb'); ?>

AWeb current makes no use of the PowerPC processor on the Amiga. This in particular has an impact on image decoding. Currently I'm using PowerPC datatypes which do decode quickly but have some drawbacks, the most obvious being no progressive decoding

I have partially ported the example ILBM decoder plugin to the PPC. The plugin uses two processes, one to decode the data into a format that can be displayed, and one to actually display the data. I have converted the decoder subtask to use the PPC processor.

Unfortunatly performance has actually gone down!

This is due to the lengthy context switch delay when swapping from the PowerPC to the 68k processor. While this delay isn't huge, there is a lot of swapping going on in this simple decoder. ObtaintaskSemaphore(), ReadPixelLine8(), WritePixelLine8(), ReleaseSemaphore(), UpdateTaskAttrs() are called in ReadBody() once for each line of the image. That is 10 context switches per image line. Every time a new colour is encountered, ObtainBestPen() is also called.

To speed up this decoder, a PPC replacement for Read and WritePixelLine8() is required. The PPC Semaphore system should also be used. The WarpOS semaphore system is not compatible with the exec system, the semaphore is used to prevent collisions with the main task in the plugin, which is currently 68k, and also with aweb itself. Converting the main task to PPC shouldn't be difficult (very easy actually), but the semaphore shared with AWeb will have to stay as an exec semaphore, so a context switch is unavoidable here. However it isn't very useful to spend too much time optimising this plugin as ILBM images are rare on the web and this plugin is very inefficent by design. This exercise was a to work out how a combined 68k and ppc plugin could be made.

The source is somewhat messy, with a lot of debugging statements thrown in. It requires vbcc to compile and the makefile suffers somewhat from using GNU make which doesn't support assigns.

A PowerPC JPEG plugin