On Friday 17 July 2009, Alexis Ménard wrote:
> I like the new method and deprecate the old one if it's not anymore needed.
the old method is just fine for "yes, cache this now" and is indeed simpler to
use (no need to ensure a unique id, e.g.), the new method would be for the "i
MAY want to cach
On Friday 17 July 2009, Aaron J. Seigo wrote:
> On Friday 17 July 2009, Marco Martin wrote:
> > and still, in the case of an applet with many subwidgets, independent
> > timers can do really a big signal storm, so i still kinda like more the
> > pointer approach :p
>
> yes, having a single timer fo
I like the new method and deprecate the old one if it's not anymore needed.
On Friday, July 17, 2009, Aaron J. Seigo wrote:
> On Friday 17 July 2009, Marco Martin wrote:
>> and still, in the case of an applet with many subwidgets, independent
>> timers can do really a big signal storm, so i still
On Friday 17 July 2009, Marco Martin wrote:
> and still, in the case of an applet with many subwidgets, independent
> timers can do really a big signal storm, so i still kinda like more the
> pointer approach :p
yes, having a single timer for this is a nice win the pointer thing is as
bit of
On Thursday 16 July 2009, Marco Martin wrote:
> On Thursday 16 July 2009, Aaron J. Seigo wrote:
> > On Thursday 16 July 2009, Marco Martin wrote:
> > > but a sick idea come to my mind: what about encoding the pointer value
> > > (or another random number, whatever) into the key? :p
> > > a key will
On Thursday 16 July 2009, Aaron J. Seigo wrote:
> On Thursday 16 July 2009, Marco Martin wrote:
> > but a sick idea come to my mind: what about encoding the pointer value
> > (or another random number, whatever) into the key? :p
> > a key will have the form
> > 7635865:path_300_200_blahblah
>
> how
Crappy idea, API will be ugly and will lead to errors.
Timer is the best approach.
On Thu, Jul 16, 2009 at 9:03 PM, Alexis Ménard wrote:
>
>
> On Thu, Jul 16, 2009 at 9:00 PM, Marco Martin wrote:
>
>> On Thursday 16 July 2009, Aaron J. Seigo wrote:
>> > On Thursday 16 July 2009, Marco Martin w
On Thu, Jul 16, 2009 at 9:00 PM, Marco Martin wrote:
> On Thursday 16 July 2009, Aaron J. Seigo wrote:
> > On Thursday 16 July 2009, Marco Martin wrote:
> > > but a sick idea come to my mind: what about encoding the pointer value
> > > (or another random number, whatever) into the key? :p
> > > a
On Thursday 16 July 2009, Aaron J. Seigo wrote:
> On Thursday 16 July 2009, Marco Martin wrote:
> > but a sick idea come to my mind: what about encoding the pointer value
> > (or another random number, whatever) into the key? :p
> > a key will have the form
> > 7635865:path_300_200_blahblah
>
> how
On Thursday 16 July 2009, Marco Martin wrote:
> but a sick idea come to my mind: what about encoding the pointer value (or
> another random number, whatever) into the key? :p
> a key will have the form
> 7635865:path_300_200_blahblah
how will this work between sessions? (new pointer values)
betwee
On Thursday 16 July 2009, Marco Martin wrote:
> On Thursday 16 July 2009, Aaron J. Seigo wrote:
> > On Wednesday 15 July 2009, Marco Martin wrote:
> > > a way could be like now, parsing the key and throwing away other sizes
> > > of the same framesvg, or just revert that commit...
> >
> > i think t
On Thursday 16 July 2009, Aaron J. Seigo wrote:
> On Wednesday 15 July 2009, Marco Martin wrote:
> > a way could be like now, parsing the key and throwing away other sizes of
> > the same framesvg, or just revert that commit...
>
> i think the patch you attached will also kill other valid pixmaps t
On Wednesday 15 July 2009, Marco Martin wrote:
> a way could be like now, parsing the key and throwing away other sizes of
> the same framesvg, or just revert that commit...
i think the patch you attached will also kill other valid pixmaps to be
cached: two plasmoids with the same svg but rendere
On Wednesday 15 July 2009, Martin Gräßlin wrote:
> Am Mittwoch 15 Juli 2009 23:06:42 schrieb Marco Martin:
> > Hi all,
> > talking with Alexis at akademy, we figured out something realy horrible
> > was happening during the caching of plasma svgs, because when an applet
> > is quickly resized, plas
Am Mittwoch 15 Juli 2009 23:06:42 schrieb Marco Martin:
> Hi all,
> talking with Alexis at akademy, we figured out something realy horrible was
> happening during the caching of plasma svgs, because when an applet is
> quickly resized, plasma cpu and disk usage spikes, actually passing all the
> ti
Hi all,
talking with Alexis at akademy, we figured out something realy horrible was
happening during the caching of plasma svgs, because when an applet is
quickly resized, plasma cpu and disk usage spikes, actually passing all the
time compressing images and writing them to the disk.
so i looked
16 matches
Mail list logo
