Dillo v3.1.1-119-g140d9ebd
|
Representation of the image data is done by dw::core::Imgbuf, see there for details. Drawing is done by dw::core::View (dw::core::View::drawImage).
Since dw::core::Imgbuf provides memory management based on reference counting, there may be an 1-to-n relation from image renderers (image widgets or backgrounds, see below) and dw::core::Imgbuf. Since dw::core::Imgbuf does not know about renderers, but just provides rendering functionality, the caller must (typically after calling dw::core::Imgbuf::copyRow) notify all renderers connected to the buffer.
Generally, there are no restrictions on how to manage dw::core::Imgbuf; but to handle image data from web resources, the interface dw::core::ImgRenderer should be implemented. It is again wrapped by DilloImage (to make access from the C part possible, since dw::core::ImgRenderer is written in C++), which is referenced by DilloWeb. There are two positions where retrieving image data is initiated:
Both are described in detail below. Notice that the code is quite similar; only the implementation of dw::core::ImgRenderer differs.
At this time, dw::core::ImgRenderer has got two methods (see more documentation there):
This is the simplest renderer, displaying an image. For each row to be drawn,
dw::Image automatically scales the dw::core::Imgbuf, the root buffer should be passed to dw::Image::setBuffer.
Since background images are style resources, they are associated with dw::core::style::Style, as dw::core::style::StyleImage, which is handled in a similar way (reference counting etc.) as dw::core::style::Color and dw::core::style::Font, although it is concrete and not platform-dependant.
The actual renderer (passed to Web) is an instance of dw::core::ImgRendererDist (distributes all calls to a set of other instances of dw::core::ImgRenderer), which contains two kinds of renderers:
This diagram gives an comprehensive overview:
dw::core::style::StyleImage extends lout::signal::ObservedObject, so that deleting this instance can be connected to code dealing with cache clients etc. See StyleImageDeletionReceiver and how it is attached in StyleEngine::apply ("case CSS_PROPERTY_BACKGROUND_IMAGE").
(Mostly related to image backgrounds, when not otherwise mentioned.)
Configurability, security/privacy aspects, etc.,** which are currently available for image widgets, should be adopted. Perhaps some more configuration options specially for background images.
Background-attachment** is not yet implemented, and will be postponed.
Calls to dw::core::ImgRenderer::fatal** are incomplete. As an example, it is not called, when connecting to a server fails. (And so, as far as I see, no cache client is started.)
Alpha support:** (not related to image backgrounds) currently alpha support (and also colormap management) is done in dicache, while dw::Image is only created with type RGB. This leads to several problems:
The solution is basicly simple: keep alpha support out of dicache; instead implement RGBA in dw::Image. As it seems, the main problem is alpha support in FLTK/X11.
Drawing background images row by row may become slow. As an alternative, dw::core::ImgRenderer::finish could be used. However, drawing row by row could become an option.* There is now dw::core::style::drawBackgroundLineByLine, which can be changed in the code, and is set to false. The old code still exists, so changing this to true activates again drawing line by line.
(For image widgets, this could also become an option: in contexts, when image data is retrieved in a very fast way.)