130 lines
4.3 KiB
Plaintext
130 lines
4.3 KiB
Plaintext
January 2009, --Jcid
|
|
|
|
Update June 2015: See also doc/dw-images-and-backgrounds.doc, or
|
|
../html/dw-images-and-backgrounds.html (generated by doxygen).
|
|
|
|
------
|
|
IMAGES
|
|
------
|
|
|
|
* 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 fed 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_parms
|
|
a_Dicache_set_cmap (only for indexed-GIF images)
|
|
a_Dicache_write
|
|
a_Dicache_new_scan (MAY be called here or after set_cmap)
|
|
a_Dicache_close
|
|
|
|
|
|
* The dicache methods call the necessary functions to connect
|
|
with the widget code. This is done by calling image.c functions:
|
|
|
|
a_Image_set_parms
|
|
a_Image_set_cmap
|
|
a_Image_write
|
|
a_Image_new_scan
|
|
a_Image_close
|
|
|
|
* 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
|
|
a_Dicache_callback().
|
|
|
|
|
|
-----------
|
|
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
|
|
code:
|
|
|
|
- DilloImage (image.hh)
|
|
- DICacheEntry (dicache.h)
|
|
- dw::Image (class Image in dw/image.hh)
|
|
- core::Imgbuf (imgbuf.hh)
|
|
|