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

List:       kfm-devel
Subject:    Re: idea : faster pixmap loading for opMenu
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-04-29 17:48:31
[Download RAW message or body]

On Thu, 29 Apr 1999, David Faure wrote:

> On Thu, Apr 29, 1999 at 03:19:41PM +0200, Simon Hausmann wrote:
> > On Thu, 29 Apr 1999, David Faure wrote:
> > 
> > > Comments please !! :)
> > 
> > Ooops, sorry... it seems I didn't take notice of this mail ;-)
> > 
> > > Simon ?
> > > Torben, are you still alive ? :-D
> > > 
> > > Anybody else ?
> > > 
> > > This would be even *source* incompatible, so I need approval before I start 
> > > doing this !!
> > > 
> > > On Sat, Apr 24, 1999 at 04:50:33PM +0200, David Faure wrote:
> > > > If one has a lot of bookmarks, creating a new view is VERY long.
> > > > This is because converting pixmaps via UIUtils for each item is VERY long.
> > > > (And it's silly, since most items have the exact SAME icon).
> > > > 
> > > > I see two solutions :
> > > > * We could create the bookmark menu when it's aboutToShow(), but that's a
> > > > kludge, and it's slow for the user.
> > > > * We could add new methods in opMenu* that would take a pixmap file name and
> > > > use KPixmapCache instead. (But that would make partsui rely on kio - is
> > > > that a problem ?)
> > > > The new methods would be alternatives to insertItem11 and insertItem12.
> > > > (... having a look). Wow, lots of methods take a Pixmap as argument :
> > > > 
> > > > long insertItem2 ( in Pixmap pixmap, in Object receiver, in string member, in \
> > > > long accel /* = 0 */ ); long insertItem3 ( in Pixmap pixmap, in wstring text, \
> > > > in Object receiver, in string member, in long accel /* = 0 */ ); long \
> > > > insertItem5 ( in Pixmap pixmap, in Object receiver, in string member, in long \
> > > > accel, in long id, in long index /* = -1 */ ); long insertItem6 ( in Pixmap \
> > > > pixmap, in wstring text, in Object receiver, in string member, in long accel, \
> > > > in long id, in long index /* = -1 */ ); long insertItem9 ( in Pixmap pixmap, \
> > > > in long id /* = -1 */, in long index /* = -1 */ ); long insertItem10 ( in \
> > > > Pixmap pixmap, out Menu popup, in long id /* = -1 */, in long index /* = -1 \
> > > > */ ); long insertItem11 ( in Pixmap pixmap, in wstring text, in long id /* = \
> > > > -1 */, in long index /* = -1 */ ); long insertItem12 ( in Pixmap pixmap, in \
> > > > wstring text, out Menu popup, in long id /* = -1 */, in long index /* = -1 */ \
> > > > );  
> > > > The bookmark menu only needs 11 and 12, but, for completeness.....
> > > > 
> > > > Or should we change all those methods to take the pixmap name instead of
> > > > the pixmap itself and force everybody to use this mechanism ?
> > > > 
> > > > I think it's a lot faster to make the 'host application' load the pixmap
> > > > (or find it in its cache) than the current system (i.e. load the pixmap,
> > > > convert the pixmap, send it via corba, and let the host application decode
> > > > it).
> > > > 
> > > > Opinions ?
> > > > 
> > > > Does the to-come cache server make this discussion obsolete ? I don't think 
> > > > so, since it will only change the cache mechanism. My concern is about the
> > > > opMenu methods above which are very slow if used in a loop.
> > > > 
> > 
> > Hm, you have a point here. I don't know anything about a to-come cache
> > server, but as far as I remember there was once a similar discussion on
> > kde-devel about system-wide pixmap caching in general.
> > I think it was Mosfet who lead the discussion, he might know details.
> > (and as KThemeMan(tm) ;) he has to deal with pixmap caching anyway)
> 
> I think it's a different issue.
> Even when system-wide pixmap caching exists, we have to choose between
> sending the pixmap via OP, in insertItemXXX (as I think would have probably 
> happened if I hadn't brought up this discussion) and sending only the
> filename via OP (i.e. make the 'host app' use the system-wide cache, not
> the client).
> So IMHO the problem I mention here will NOT become obsolete when we have a
> global pixmap cache.

Hm, ooops, you're right :-)

> > In any way I vote for keeping source compatibility, especially since it's
> > sometimes useful to "manually" load a pixmap. Example: In koffice/pics
> > there's a stop.xpm . KFM has the same icon name. So if I load "stop.xpm"
> > in a KOffice App then the "koffice-stop" icon gets loaded, but what if I
> > want the kfm icon? That's why I think additional insertItem123563453463
> > methods are the better solution, although the incremental naming might
> > confuse developers ;-) .
> 
> This pixmap name clash is step by step fixed, by me, and by ?Jost? (not
> sure of his name, now).
> You can note some of the koffice pixmaps have been renamed already, some
> time ago. We should go on in that way.

Ah, good idea!

> But I agree that we'll have problems if we pass only the filename if the
> icon is in the client application's own directory (share/apps/..../),
> because then the host can't find it.
> Two solutions : pass a fullname, or keep the current methods.

I still vote for additional methods: Being source compatible by keeping
the old pixmap transfer stuff and providing new methods for faster pixmap
loading.

Well, on the one hand this bloats up the whole interface (and the IDL
generated code) a lot, but on the other hand keeping source compatibility
is a thing I started to like, especially after my OpenParts-Unicode
conversion, which involved hundres of changes all over Konqy/KOffice ;-)

And beside this: Switching to the new methods breaks pseudo-compatibility
to the qt/kdeui classes, and I think keeping this compatibility is
important keep the whole usage of PartsUI easier.


btw: I agree that using a lot of pixmaps in menus is slow using the
current UIUtils conversion stuff, but otoh: This conversion is only
done when (re-)activating the MainView part (in case of Konqy) , and I'm
not sure whether this will be done so often? (currently it is done only
once on startup) 
And I think most of the time when using Konqueror only part child switches
occur (which do not involve massive changes in Konqy's GUI ) .

But I know, my argument is not very strong since Part
activation/deactivation is done pretty often in KOffice, and when
switching between huge GUIs like the ones from KPresenter and KWord I can
understand you :-)

Ciao,
  Simon

--
Simon Hausmann       <hausmann@kde.org>
http://www.kde.org/  <tronical@gmx.net>


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