Re: Systemtray benchmarks
On Thursday 02 April 2009, Marco Martin wrote: agreed. it's guaranteed to be usable by everyone, even weirdos without png support ;) , and looks faster. so +1 for that. to be really portable is enough as is now that assumes argb32 images or an overcomplication like galago? assuming 32 bbp images in argb format is safe. -- 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: Systemtray benchmarks
On Thursday 02 April 2009, Aaron J. Seigo wrote: On Thursday 02 April 2009, Marco Martin wrote: agreed. it's guaranteed to be usable by everyone, even weirdos without png support ;) , and looks faster. so +1 for that. to be really portable is enough as is now that assumes argb32 images or an overcomplication like galago? assuming 32 bbp images in argb format is safe. ok soo, that's basically it... only thing i was thinking about was if shouldn't be the case of putting the dbus interface on another file, so removing the properties called by dbus from the public api... would be cleaner but also a quite big amount of duplication... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray benchmarks
On Thursday 02 April 2009, Marco Martin wrote: On Thursday 02 April 2009, Aaron J. Seigo wrote: On Thursday 02 April 2009, Marco Martin wrote: agreed. it's guaranteed to be usable by everyone, even weirdos without png support ;) , and looks faster. so +1 for that. to be really portable is enough as is now that assumes argb32 images or an overcomplication like galago? assuming 32 bbp images in argb format is safe. ok soo, that's basically it... only thing i was thinking about was if shouldn't be the case of putting the dbus interface on another file, so removing the properties called by dbus from the public api... would be cleaner but also a quite big amount of duplication... for a class that we'd like to export as part of a public API, it's probably worth it. -- 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: Systemtray benchmarks
On Wednesday 01 April 2009, Rob Scheepmaker wrote: On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 I'm interested: could you also run this benchmark for 96x96 icons, which is often used for the icon in notification icons? Currently it also uses png's to transfer this data, but it wouldn't surprise me if with those bigger icons png's are faster. here we go: png: 8.97 8.96 8.92 8.76 9 8.86 9.03 9.07 8.77 9.19 average 8.95 raw 2.868 2.698 2.821 2.915 2.877 2.816 2.819 2.685 2.790 2.783 average 2.807 in this case the difference is so embrassing that i wonder if there is something wrong but yeah, it seems to justify using raw :p Cheers, Marco Martin Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray benchmarks
On Wednesday 01 April 2009 11:09:52 Marco Martin wrote: On Wednesday 01 April 2009, Rob Scheepmaker wrote: On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 I'm interested: could you also run this benchmark for 96x96 icons, which is often used for the icon in notification icons? Currently it also uses png's to transfer this data, but it wouldn't surprise me if with those bigger icons png's are faster. here we go: png: 8.97 8.96 8.92 8.76 9 8.86 9.03 9.07 8.77 9.19 average 8.95 raw 2.868 2.698 2.821 2.915 2.877 2.816 2.819 2.685 2.790 2.783 average 2.807 in this case the difference is so embrassing that i wonder if there is something wrong but yeah, it seems to justify using raw :p Ok, thanks for running this benchmark: indeed dbus seems a lot faster then I expected it to be. I'd better also move the notification's image data to raw format. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray benchmarks
Hi Marco, Just my 2 cents here. If the uncompressed raw data works and it's not an unmaintainable beast, I'd go for it for the simple fact that having to compress-transmit-decompress could be not so handy and sounds more like a hack. If I got you right: decompress means back to raw data? If so, I'd really prefer the second approach. Adding png would be an useless layer of complexity, I think. And, as a bonus point, if your benchmarks are correct, it looks to me that the performance gain is kinda remarkable. It would be nice to see the code of both approaches to get a better idea on it. Oh, forgot to say: great work :) On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 a) converting to png passing the data over dbus and uncompressing again, 10 runs: 3.442 3.404 3.474 3.262 3.254 3.474 3.354 3.584 3.415 3.363 average 3.403 seconds 293.858 icons/second b) passing uncompressed raw data, (just image.bits() copied) 2.620 2.656 2.512 2.584 2.588 2.560 2.541 2.552 2.584 2.520 average 2.572 seconds 388.802 icons/second that's faster, even if not mindboggling faster still not tried with pixmap handles, should be way faster, but still think portability concerns are way too much now, with png is where the code and the api is simpler/nicer but is the slowest with raw data it would be compatibe with toolkits that don't have png (there are things with dbus support where png could be a prblem? seems unlikely but..) s, opinions? :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: Systemtray benchmarks
On Tuesday 31 March 2009, Dario Freddi wrote: Hi Marco, Just my 2 cents here. If the uncompressed raw data works and it's not an unmaintainable beast, I'd go for it for the simple fact that having to compress-transmit-decompress could be not so handy and sounds more like a hack. If I got you right: decompress means back to raw data? If so, I'd really prefer the second approach. Adding png would be an useless layer of complexity, I think. agreed. it's guaranteed to be usable by everyone, even weirdos without png support ;) , and looks faster. so +1 for that. for the 10 icons in my system tray right now, it would take ~25-30ms to transfer them. that's approximately 40x faster than it currently takes just one of the icons to show up in the tray right now. wow. Oh, forgot to say: great work :) +1 -- 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: Systemtray benchmarks
On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 I'm interested: could you also run this benchmark for 96x96 icons, which is often used for the icon in notification icons? Currently it also uses png's to transfer this data, but it wouldn't surprise me if with those bigger icons png's are faster. Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
