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

List:       kde-devel
Subject:    Re: mmaping icons
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1999-02-16 9:25:38
[Download RAW message or body]

On Mon, 15 Feb 1999, Robert Schöftner wrote:
>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.
>

Make it a "service" managed by a Service Manager. This service manager is then
started in startkde or even earlier. The service manager doesn't have to be
(and shouldn't be) graphical. It could however expose an IDL interface so
external programs could manage it. This has some very interesting potential.
Perhaps I'll work some things out in the next few weeks...

BDR

>* 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]