Re: more on the systemtray
On Monday 30 March 2009, Marco Martin wrote: > On Monday 30 March 2009, Aaron J. Seigo wrote: > > On Saturday 28 March 2009, Marco Martin wrote: > > eventually, should our hopes and dreams come true ;), this would see one > > more rename from org.kde.* to org.freedesktop.* > > yeah, but should be done only after, right? having it steal a namespace > wouldn't be so nice :p yes :) > > have you done any measuring of these two approaches? boring work, but it > > would be interesting to see what sort of throughput we get for 22x22, > > 32x32 and 256x256 pixmaps as PNGs or raw data. the raw data might be > > nicer for apps that don't have png capabilities in their toolkits, > > assuming it's fast enough. > > eh, nope, and i was hesitant since i know how easy is to do benchmarks that > are totally bullshit :p > can try, at least to have a rough idea it's pretty easy, really: just see how long it takes to send 1000 pixmaps across the bus using the two methods. this is a lot easier than measuring memory (hard to tease it out of the kernel and separate all the noise from the data) or graphics speed (where there are so many layers and subsystems at play) ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: more on the systemtray
On Monday 30 March 2009, Aaron J. Seigo wrote: > On Saturday 28 March 2009, Marco Martin wrote: > > now the services are called org.kde.SystemTray and > > org.kde.systemTrayDaemon, since the client is called KNotificationIcon, i > > think the services would make more sense as > > org.kde.NotificationIcon and org.kde.NotificationIconWatcher > > straightforward but would require a quite massive renaming of stuff... > > so .. just to screw things up completely (that's what i do, right? ;), i've > been chaffing at the term "icon" since that may or may not at all be what > happens. and i dislike "system tray" as well. now .. our "friends" in > redmond (and GNOME?) apparently call this the "notification area" and tbh > that's really not such a bad name. > > how about ... > > org.kde.NotificationAreaWatcher and org.kde.NotificationAreaEntry? yes, it makes sense, so i think i'll use it also for the class name of the client library, next days will be a triumph of svn mv yee :) > eventually, should our hopes and dreams come true ;), this would see one > more rename from org.kde.* to org.freedesktop.* yeah, but should be done only after, right? having it steal a namespace wouldn't be so nice :p > > also, since usually the dbus exposed functions and methids are uppercase, > > should i do so also there? > > probably ... bleh. > > > images passing: > > still didn't understood what should be the better way to pass images over > > dbus, now it passes the PNG data, and this is probably the most portable > > way, but also really slow (it has to compress /uncompress the image every > > time) another way could be to pass the raw pixel data, that would take > > dbus for a bit longer but faster to write/load, it would need additional > > info (the overkill galago data or just width, height, data and assume > > that is always argb32) > > have you done any measuring of these two approaches? boring work, but it > would be interesting to see what sort of throughput we get for 22x22, 32x32 > and 256x256 pixmaps as PNGs or raw data. the raw data might be nicer for > apps that don't have png capabilities in their toolkits, assuming it's fast > enough. eh, nope, and i was hesitant since i know how easy is to do benchmarks that are totally bullshit :p can try, at least to have a rough idea > > > another way could be as fredrik suggested me today, just pass x11 pixmaps > > handles, no copy, really fast, but portability issues? > > yeah, i think the portability issues sort of kill that. these aren't huge > chunks of data, really. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: more on the systemtray
On Saturday 28 March 2009, Marco Martin wrote: > now the services are called org.kde.SystemTray and > org.kde.systemTrayDaemon, since the client is called KNotificationIcon, i > think the services would make more sense as > org.kde.NotificationIcon and org.kde.NotificationIconWatcher > straightforward but would require a quite massive renaming of stuff... so .. just to screw things up completely (that's what i do, right? ;), i've been chaffing at the term "icon" since that may or may not at all be what happens. and i dislike "system tray" as well. now .. our "friends" in redmond (and GNOME?) apparently call this the "notification area" and tbh that's really not such a bad name. how about ... org.kde.NotificationAreaWatcher and org.kde.NotificationAreaEntry? eventually, should our hopes and dreams come true ;), this would see one more rename from org.kde.* to org.freedesktop.* > also, since usually the dbus exposed functions and methids are uppercase, > should i do so also there? probably ... bleh. > images passing: > still didn't understood what should be the better way to pass images over > dbus, now it passes the PNG data, and this is probably the most portable > way, but also really slow (it has to compress /uncompress the image every > time) another way could be to pass the raw pixel data, that would take dbus > for a bit longer but faster to write/load, it would need additional info > (the overkill galago data or just width, height, data and assume that is > always argb32) have you done any measuring of these two approaches? boring work, but it would be interesting to see what sort of throughput we get for 22x22, 32x32 and 256x256 pixmaps as PNGs or raw data. the raw data might be nicer for apps that don't have png capabilities in their toolkits, assuming it's fast enough. > another way could be as fredrik suggested me today, just pass x11 pixmaps > handles, no copy, really fast, but portability issues? yeah, i think the portability issues sort of kill that. these aren't huge chunks of data, really. -- Aaron J. Seigo, today's spoilsport humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: more on the systemtray
On Sat, Mar 28, 2009 at 4:03 PM, Marco Martin wrote: > another way could be as fredrik suggested me today, just pass x11 pixmaps > handles, no copy, really fast, but portability issues? Just a note that I wrote a test case at tokomak 2 to check that passing pixmap handles around still worked with 4.5 and it was fine. That said however, I didn't try it with the raster rendering engine which might break this. That would be a major problem for obvious reasons. Cheers Rich. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
more on the systemtray
hi all, the systray thing is coming along nicely, there are some things i still wand to get ironed out before proposing the thing on kde-core-devel, kdereviev and making the thing moving forward (even propose to freedesktop..) renames: now the services are called org.kde.SystemTray and org.kde.systemTrayDaemon, since the client is called KNotificationIcon, i think the services would make more sense as org.kde.NotificationIcon and org.kde.NotificationIconWatcher straightforward but would require a quite massive renaming of stuff... also, since usually the dbus exposed functions and methids are uppercase, should i do so also there? images passing: still didn't understood what should be the better way to pass images over dbus, now it passes the PNG data, and this is probably the most portable way, but also really slow (it has to compress /uncompress the image every time) another way could be to pass the raw pixel data, that would take dbus for a bit longer but faster to write/load, it would need additional info (the overkill galago data or just width, height, data and assume that is always argb32) another way could be as fredrik suggested me today, just pass x11 pixmaps handles, no copy, really fast, but portability issues? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
