[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: mmaping icons
From:       Robert =?ISO-8859-1?Q?Sch=F6ftner?= <r.schoeftner () magnet ! at>
Date:       1999-02-15 18:08:35
[Download RAW message or body]

Am Fri, 12 Feb 1999 schrieb Dan Pilone:
>Previously written in blue crayon:
> > David Faure (David.Faure@insa-lyon.fr) spake thusly:
> > > Hum, on second thought, if the aim is to avoid duplication of the pixmaps
> > > in memory, CORBA is _not_ the way to go for this thing. The object
> > > requested will always be copied by the ORB... What is needed is shared
> > > memory between processes.
> > 
> >   Nope, you don't need either, you just need to return an X Pixmap ID.
> > The CORBA object here is the server, not individual pixmaps. What /is/
> > needed is a way to get a QPixmap from an X resource ID ;)
>
>	I could implement the KIconLoader interface through
>CORBA, then most apps could use it with minimal change.  The problem
>like you said though is the QPixmap from the X resource ID.  If
>someone can give me some pointers on that one I'm willing to write
>this.  -- Dan
>

hi,

this is my proposal:

* a daemon (= spiritual guide :) is started somewhere, perhaps in startkde.

* the daemon puts an invisible window on the default display. (needed to send it
client-messages).

* the daemon sets a property on the root-window perhaps named something like
_KDE_PIXMAPCACHE_D[1] with the id of the hidden window, so that apps know where
to send their clientmessages. 

* the daemon sets some Atoms in the x-server for
some message-types like _KDE_PIXCD_REQ_MINI, _KDE_PIXCD_REQ_TB[2] and so on to
identify requests for different pixmaps, and some atom like _KDE_PIXCD_RETID[3]
to answer requests.

* when receiving a clientmessage of type [2], lookup & load
the pixmap, send a ClientMessage back with type [3], clientdata set to
pixmap-id and serial of request


an app does the following (that means KIconLoader) to request a pixmap:

* lookup [1] on the root-window and get the window-id

* send the window a ClientMessage with type set to [2], clientdata set to
pixmap-name (stripped down to the name w/o extension or path, length is limited
to 20 characters)

* wait for a ClientMessage of type [3], construct a QPixmap-derived object that
can be initialized with a pixmap-id, and return a reference to it...
(better const reference, these pixmaps should not be tampered with to avoid
global desktop-confusion :) waiting could be implemented in a loop that does
processOneEvent with a reasonable timeout and poll for a signal received in the
meantime from KApplication::x11EventFilter

left to think about: getting rid of pixmaps not used any more... the daemon
somehow needs to be notified if a window is destroyed, (perhaps do a XQueryTree
every now and then?)

pros: apps would not need to be changed, only small changes to kdecore needed,
does not need another rpc-mechanism that would perhaps not be otherwise needed
in an application, can be easily extended, has potential to really save memory,
reduces X11-communication (even more if daemon runs locally on the display),
perhaps increases startup-time of some apps, ...

cons aka some (academic?) problems i can see: perhaps there could be some races
in the app when waiting for a ClientMessage, killing the daemon could be a bad
thing, supporting multiple screens per display and/or different depths on
one display could be a problem, it may not be worth the effort :), ...

some estimations: a 16x16 pixmap needs about at least 600 bytes in the X-server
on a 16bit display, about 850 bytes on a 24bit display and perhaps more than 1k
with 32bit "depth". so memory and communication savings should be quite
expectable :)

needed changes to kdecore:

* completely rework KIconLoader to use this mechanism, leave current
functionality as a fallback and for use by the daemon

* put support for return-messages from the daemon into
KApplication::x11EventFilter. (this would do something like emit a signal that
KIconLoader connects to, then the signal needs to be added too).

* add constructor to KPixmap that gets an ID and constructs internal Qt-data :)
(struct QPixmap::QPixmapData {...} *data, as seen in QPixmap.h)

did i miss something?

servas,
  robert

--
Robert     GS@  PGP+       Die Justiz ist wie die Venus von Milo:
Schöftner  G++? [...]      Einen Kopf, aber keine Arme
r.schoeftner@magnet.at             -- Kommissar Navarro

[prev in list] [next in list] [prev in thread] [next in thread]