>  
>> Atom's hold integer indexes into the X server.  You store the Pixmap ID and
>> then ask for it.
> 
> So of:
> 
>         _XSETROOT_ID
>         _XROOTPMAP_ID
>         ESETROOT_PMAP_ID
> 
> Which is the one that you're supposed to use?  I assume that
> ESETROOT_PMAP_ID is the non-standard one that Eterm is looking for.
> 

I will have to read the Eterm code, I think this represents various versions of
various tools.

>> The id is however standard among GNOME, E, other wms, and I think even good
>> parts of KDE.
> 
> Hm... why would the window manager care at all?  It's not responsible for
> what happens inside the window frame, is it?  I thought the application
> was.  Of course, if the window manager itself is creating the window, then
> it IS the application. ^_^
> 

sorry, my meaning was that wmaker's tool to set backgrounds, the KDE set, etc.

>> sorta.  You say "draw my background as if I were my parent".  You get no
>> control or access.
> 
> I've noticed that if I set the background with Esetroot, then it takes
> longer for aterm to do things that involve resizing the window, like
> maximization.  Is that because aterm has to retrieve the bitmap, then
> cookie-cutter out the appropriate piece, then set the background of the
> window itself?  When I maximize, it tiles its piece of the background (that
> the old window had) multiple times over the window, then it blinks, then it
> paints it again correctly.
> 
> I assume that using parent-relative is faster, because then the X server
> handles it?  I don't see the blink in that case.
> 
> Seems like it would also increase memory usage on the part of the
> application, if it had to maintain a local copy of the bitmap somewhere.
> 

part of this is the code in aterm.  Eterm is no where near as slow in that
respect.

>> > 
>> I have not tried display recently, it may have been updated.
> 
> Well, I just tried display and wmsetbg.  I currently have bsetbg configured
> to use
> Esetroot, and aterm does not pick up the root window change.  It's still
> using the one my style set, meaning that the atom is still pointing at the
> bitmap that Esetroot used?  So I'd assume that display is one with a
> problem?
> 
> OTOH, wmsetbg apparently does "the right thing", because aterm picked up
> right away that the root had changed.  Perhaps blackbox should "adopt"
> wmsetbg. ^_^
> 

will look into this further.

Reply via email to