drf54321 at gmail.com
Tue Mar 31 23:48:54 CEST 2009
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
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
> 3.403 seconds
> 293.858 icons/second
> b) passing uncompressed raw data, (just image.bits() copied)
> 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
> 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..)
> opinions? :)
> Marco Martin
> Plasma-devel mailing list
> Plasma-devel at kde.org
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090331/8c08920b/attachment-0001.sig
More information about the Plasma-devel