FrameSvg corruption [a bit urgent]

[Marco Martin]

On Friday 16 January 2009, Ivan Čukić wrote:
> When I woke up this morning, the magic fairies have fixed the problem and
> everything worked fine...
>
> So, I decided to restore my corrupted drawing, and deleted kpc/ and plasma-
> svgelements* and now I get even worse glitches then before - even
> non-prefixed elements get drawn badly.
>
> > one thing that might be enlightening is to see if resize is getting
> > called at any point with (0, 0). resizing invalidates the cached local
> > entries and will access different entries ... though one would expect
> > that when actually drawn at whatever size the buttons are drawn they are
> > the correct size.
>
> I'm testing this now. Svg::resize gets called sometimes with (-1, -1), will
> see from where exactly.
>
> > tomorrow i'll try and write some tests to track it down. which svg
> > file(s) in particular is the problematic one(s)?
>
> There were no particular SVGs, all have problems.

the really weird thing is that i see the problem too for svgs in lancelot but 
not fron anything else :(
i get the problem for instance in the logout/shutdown etc buttons
where is exactly the code that manage those buttons?



> > why? it's not going to magically become invalid.
>
> Sometimes it does, because of a bug or something.
>
> > the theming relies in several places on the idea of non-existent
> > elements. all of the hints, for instance.
>
> So, what exactly is remembered for elements. Do we remember when an element
> doesn't exist? Why is the element that has the size 0x0 treated like it
> doesn't exist? (not that I have those elements, just asking)