view doc/Images.txt @ 1770:4779a3d891a1

trim some spaces
author corvid <>
date Wed, 24 Nov 2010 19:26:45 +0000
parents cf7f2d3312fb
line wrap: on
line source
 January 2009, --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 // Read attributes, create image, add to HTML page
       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
       Html_load_image  // Tells cache to retrieve image

Fetching from the net

*  a_Capi_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_callback, a_Jpeg_callback and a_Png_callback.

*  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)
   a_Dicache_new_scan (MAY be called here or after set_cmap)

*  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 Dw calls.

Fetching from the dicache

* a_Capi_open_url() tests the cache for the image, and the cache,
via  a_Cache_open_url(), enqueues a client for it, without asking
the  network  for the data. When the client queue is processed (a
bit later), Dicache_image() is set as the callback.

*  When  Dicache_image() is called, it sets the proper image data
decoder  (RGB)  and its data structure based on the entry's Type.
Then  it  substitutes  itself  with  a_Dicache_callback()  as the
handling function, and gets out of the way.

*  Thenceforth  the  rest  of  the  functions  calls is driven by

Misc. notes

*  Repeated images generate new cache clients, but they may share
the  imgbuf.
   Note:  Currently  there's  no  proper  support for transparent
images  (i.e.  decode  to RGBA), but most of the time they render
the  background  color  OK.  This is: when first loaded, repeated
images  share  a  background  color,  but when cached they render
correctly ;-). There's no point in trying to fix this because the
correct  solution is to decode to RGBA and let the toolkit (FLTK)
handle the transparency.

*  The  first cache-client callback (Dicache_image()) is set when
the Content-type of the image is got.

*  Later  on,  when  there's a shared imgbuf, the dicache's logic
avoids decoding it multiple times and reuses what's already done.

*  The dicache-entry and the Image structure hold bit arrays that
represent which rows have 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)