Background Image Proposal
Sasha_Vasko@osca.state.mo.us
Tue, 2 Mar 1999 15:24:50 -0600
Contents :
1. Problem Definition
2. Background
3. Solutions
4. Proposal
5. Notes
1. Problem Definition
a)Virtual Desktops is a one of the main AfterStep features, regardless on
if any desktop
management tool (like Pager) is running or not - it is available to the
User.
b)Each virtual desktop is entitled to have it's own background Image, if
that is desirable by User.
c)Background Image loading code can be quite complicated if we want
advances features like
scaling of image, centering, etc.
d)Background Image loading code is needed only once - when we load image
and after that becomes
unneeded, wasting memory laggage.
As the result of that we need to come up with the way of providing
comprehensive
per-desk background image functionality, that would not depend on any other
module, could be
removed easily and will not waste excessive resources.
In short we have to provide User with this flexible choice :
I) running no Pager no background support
II) running Pager and no background support
III) running no Pager but single desk background support
IV) running no Pager but multi desk background support
V) running Pager and multi desk background support
VI) running Pager and single desk background support ( for single
desk multiple pages users )
2. Background
2.1.Functionality
Background Image functionality essentialy consists of two parts -
a. onetime running code for image loading and possible transformations
This is the largest part of the code, including different image format
processing, image scaling and
padding. This part includes linking to external libraries for particular
image format support.
b. background switching code, that changes root background whenever desks
are switched.
this part is rather small, it consists of AfterStep message handler
detecting desk changes,
setting root background to particular image and posibly running some
external application to
display root background. It also includes setting of the root pixmap
property for aterm like
applications to use.
Due to the nature of the second part it must always be implemented as the
part of AS module,
and must continuously reside in memory.
At the same time first part of it can be implemented as simple application,
as well as a module.
It can be run once on startup (or on background change) and the discarded.
In this case we
should provide some way to make results of it's work available for the
second part.
2.2. LIBASIMAGE
At the moment libasimage includes most of the functionality needed for
background image loading,
together with image manipulation code. As a result, even if image loading
part is not needed -
it will still be linked to the program, together with all satelite libs.
2.3. AfterStep Pager
At the moment Pager is capable of all Root background maintenance tasks,
which does not seem to be
very logical in the light of previous information. Although, if image
loading functionality will be removed from
Pager we'll still need image manipulation functionality to make possible
root pixmap scaling
down to Pager size ( which is a good feature and not worse discarding ).
2.4. AfterStep Module
Running every additional AfterStep module involves sugnificant overheads no
matter how small functionality
the carry on. That includes additionalcommunication pipe, CPU usage for
processing of every
AfterStep message regardless on if its needed or not, additional memory
utilization, slower startup
process due to increased number of programs that needs to be loaded.
3. Solutions
a) Image loading functionality needs to be separated from everything else
b) Image Loading functionality needs to be removed from Pager
c) libasimage needs to be devided in two, to provide means to for solution
a
d) additional module is needed for providing background switching
capabilities
in case Pager is not running and multiple desk background support is
needed (Asetroot).
Or possibly image switching functionality integrated back into afterstep
itself.
e) separate image loading prog needs to be written/spawned off Pager or
Asetroot
code.
f) perdesk background image information needs to be stored in X properties,
to provide
sharing between different parts.
4. Proposal
4.1. Image loading functionality must be removed completely from the Pager.
Background image
switching functionality can be left in there, with possibility to remove
it at compile time
using --enable-pager-background=no configure option.
4.2. Asetroot can be left intact except for making it comform to X property
background image
info storing protocol (see below) and backgroun image description file
format.
That will allow for smooth and simple operation under scenarios: III and IV
4.3. Additional prog (ASBGLoader) can be written/spawned off Pager or
Asetroot code to provide
image loading only functionality. That prog will be run once per session or
when background
is changed, and later on discarded. That should allow eficient operation
under scenarios: V and VI
It will be taking two arguments - starting and ending desk # ( just like
Pager does ) for flexibility
4.4. The following background image X property protocol can be used :
One property per desk :
for each desk with background image X property with name :
"_AS_BACKGROUND_DESK<desk#>" will be created.
If image is loaded into memory it will have XA_PIXMAP type, and will
hold pixmap ID
If image should be displayed by external app it will have XA_STRING type
and will hold
command line ( without prog name ) that needs to be run to display
image.
4.5. separate configuration file, dedicated to image to desk relationtip
needs to be created.
In this file image definition and desk<->image definitions needs to be
separated to enable
one image for several desks type of relationship.
Here is the possible format for it :
###########################################################################
#
#here goes image definitions
<Image_definition1>
<Image_definition2>
.
.
.
<Image_definitionN>
#here goes image to desk definitions, like so:
# DestopImage desk# ImageDefinitionName
DesktopImage 1 Image_Definition_Name1
DesktopImage 2 Image_Definition_Name2
DesktopImage 3 Image_Definition_Name3
.
.
.
DesktopImage N Image_Definition_NameN
Default Image_Definition_Name # image to
be displayed on root background
# by default on startup.
#Where Image_definition will have the following format :
MyImage <Image_Definition_Name>
Inherit <Image_Definition_Name>
ImageFile <file_name>
ClipRegion <geometry> # to enable
clipping the part of original image prior
# to any transformation
Transformation
Tile|Scale|ScaleVertical|ScaleHorisontal|NoTile|NoTileVertical|
NoTileHorisontal|Center|ScaleTo
<geometry>
Brightness <shading%>
TintColor <tint_color>
ExternalLoaderArgs <args> # if user wants to
use external loader
~MyImage
###########################################################################
#########
Note that most of the code needed to implement all this features is already
in libasimage.
4.6. LIBASIMAGE needs to be split up in two - libasimload and libasimtools,
like it is done in fltk tool kit.
If that will not be done there will not be much gain in removing image
loading
stuff from Pager.
5. Notes.
I'm going to remove image loading functionality from Pager anyway.
Also I'm going to implement this separate image loading prog (ASBGLoader)
anyway too,
if only for myself. So there will not be much trouble in trying it and,
possibly,
adding to AS tree permanently if it will perform satisfactory.
That leaves us with the following things to discuss :
a) X property protocol.
b) background image description file format.
c) Asetroot role in all that.
d) libasimage splitting
That is all.
Sasha.