view doc/Images.txt @ 503:00b31843839b

implement various apply() methods
author Johannes Hofmann <>
date Wed, 29 Oct 2008 16:44:28 +0100
parents 17f7b0db59ca
children ccdc02768890
line wrap: on
line source
 December 2007, --Jcid


* When a image tag is found within a HTML page, Html_tag_open_img
handles it by:

   - Parsing & getting attribute values.
   - Creating a new image structure (DilloImage) and its
     associated widget (DwImage).
     i.e. If 'Image' is the var for the structure, then
          'Image->dw' is the widget.
   - Requesting the image to be feeded by the cache.
   - Sending some info to the browser interface.

* The  cache  can  either request the image data from the net, or
feed it directly from the dicache (decompressed image cache).

*  Both  processes  are  somewhat different because the first one
requires to decode the image data into RGB format, and the second
one has the whole data already decoded.

*  Regardless of the RGB-data feeding method, the decoded data is
passed to the widget (DwImage) and drawn in a streamed way.
   Note that INDEXED images are also decoded into RGB format.

   Html_tag_open_img    // IMG element processing
     Html_add_new_image // Reat attributes, create image, add to HTML page
     Html_load_image    // Tells cache to retrieve image
       a_Image_new      // Create a 'DilloImage' data structure, to coordinate
                        // decoded image-data transfer to an 'Imgbuf'.
       Html_add_widget  // Adds the dw::Image to the page

Fetching from the net

*  a_Cache_open_url  initiates  the  resource  request,  and when
finally  the answer arrives, the HTTP header is examined for MIME
type  and  either the GIF or PNG or JPEG decoder is set to handle
the incoming data stream.
   Decoding functions: a_Gif_image, a_Jpeg_image and a_Png_image.

*  The  decoding  function calls the following dicache methods as
the data is processed (listed in order):

   a_Dicache_set_cmap (only for indexed-GIF images)

*  The  dicache  methods  call the necessary functions to connect
with the widget code. This is done by calling image.c functions:

*  The  functions  in  image.c  make  the required a_Dw_image_...

Fetching from the dicache

*  a_Cache_open_url  tests  the cache for the image, and directly
enqueues  a  cache  client for it, without asking the network for
the  data.  When the client queue is processed (a bit later), the
decoder is selected based on the cache entry Type.

* When the decoder is called, it tests the dicache for the image;
if  the  image  is  found, then it sets a_Dicache_callback as the
handling  function  and gets out of the way (no image decoding is

*   Later  on,  the  DwImage  buffer  is  set  to  reference  the
dicache-entry's  buffer  and  the  rest of the functions calls is
driven by a_Dicache_callback.

Misc. notes

*  Repeated  images  generate  new cache clients, but only one of
them  (the first) is handled with a_Dicache_* functions, the rest
is done with a_Dicache_callback..

*  The  cache-client callback is set when the Content-type of the
image is got. It can be: a_Png_image, a_Gif_image or a_Jpeg_image
Those  are  called  'decoders'  because their main function is to
translate the original data into RGB format.

*  Later  on,  the decoder can substitute itself, if it finds the
image has been already decoded, with a_Dicache_callback function.
This avoids decoding it twice.

*  The dicache-entry and the Image structure hold bit arrays that
represent which rows had been decoded.

* The image processing can be found in the following sources:

  - image.{cc,hh}
  - dicache.[ch]
  - gif.[ch], png.[ch], jpeg.[ch]
  - dw/image.{cc,hh}

*  Bear  in  mind  that  there are four data structures for image

  - DilloImage (image.hh)
  - DICacheEntry (dicache.h)
  - dw::Image (class Image in dw/image.hh)
  - core::Imgbuf (imgbuf.hh)