Re: Background Image Proposal

Rafal Wierzbicki (rafal@mcss.cas.mcmaster.ca)
Wed, 3 Mar 1999 02:19:18 -0500 (EST)



> 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
> Used
   
	I agree entirely

> 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.

  yes, this is done in asetroot now....

> d)Background Image loading code is needed only once - when we load image
> and after that becomes
> unneeded, wasting memory laggage.
	
  This is untrue, why?  a)
			  There is image loading code in Wharf, afterstep,
another module or program which uses the same libraries etc will not
increase memory usage greatly.  It would only make sense to get rid of ALL
image loading routines from all of afterstep and use a program like
Esetroot to store images in properties.  Talk about memory waste.

			b)
			  Having yet another *external* program do image
loading makes it more complicated for users to use, it makes it more
difficult for maintainers to maintain.

> 
> 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.

   As far as I see it what you're suggesting is going to be a great waste
of both memory and cpu usage.

> 
> 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 )

	Why complicate things so much??? I really don't understand what
you're trying to achieve here.  What I'm suggesting instead is let's make
Pager Pager only.  The tasks of a pager are really to maintain a visual
small scale interpretation of what's happening on the screen and allow for
easy desk change.  Your suggestion complicates things way too much.
Instead I propose 3 options for Pager.  Pager with color only, Pager with
a scaled down desktop background and transparent Pager with optional
tinting.  AfterStep manages desks, Pager's *only* job is to make them easy
accessible.

> 
> 
> 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.
> 
	All this is already in afterstep, asetroot does what you're asking
for, image loading code resides in memory at all times, you can't get rid
of it.  Again I think you're trying to overcomplicate things needlessly.

 > 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

 I agree.

> using --enable-pager-background=no configure option.
> 4.2. Asetroot can be left intact except for making it comform to X property
> background image

	This has to be coded in.

>  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

	I entirely disagree with you on this point.
> 
> 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.
	

	_AS_BG_DESK sounds good, the other property seems pointless.

All in all, at least we're moving in some logical direction but the idea
of an external application to do image loading is wrong. Asetroot seems
the logical choice to do everything that needs to be done with the
background.  As far as splitting asimagelib into 2 parts I agree, leave
the image *loading* in one part and all other transparency etc in the
other part.  That way asetroot can link only with the image loading part
thus reducing memory usage.
Another thing is, since asetroot already exists and does a good job at
what it does, why not decide on the protocol for accessing the desktop
backgrounds instead?

I'm sorry, I disagree with you on almost everything in your message but I
really think that what you're suggesting is overcomplicated, it relies on
too many factors for a simple thing as putting an image on the background.
I think that asetroot is the better alternative for managing desktop
backgrounds, it's a lot simpler, cleaner, there is no need for large
rewrites.  I'd rather see Pager moved to use mystyles with optional
support for grabbing the ROOT_PMAP or, as you suggested, AS_BG_DESK1 etc.


Rafal.