Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

[Wenyuan G. <guo...@gm...>]

Hi Brendan,

Taking a quick look at the GDB output I noticed this:

#6  0x08069ca0 in do_png_save (fi=0x0, fname=0xbfffd28c
"/usr/local/share/tuxmath/images/comets/cometd--1--1-cache.png",
surf=0x84c8970)
    at /home/cheezmeister/code/c/tuxmath/src/loaders.c:788

It seems the problem is: the argument "fi" passed to do_png_save is
supposed to be an opened file (FILE*) where the surface is to be
saved. It is initialized with an earlier call of "fopen" requesting
write access. Since it is NULL, it is clear that the "fopen" failed.
Do you have write access to your tuxmath install directory (in my
case, /usr/local/share/tuxmath) and whether there is enough disk
space? The caching PNG files will be written to the same directories
where the original SVG sprites are located.

Wenyuan

On Thu, Jun 10, 2010 at 11:40 PM, Brendan Luchen <bm...@ri...> wrote:
>
> Wenyuan,
>
> > Actually, only SVG based sprites are cached in PNGs. If the sprites are
> > loaded from PNGs, they are not affected at all. Cheers!
>
> Well, I meant in the event a cached PNG version is found and loaded,
> it would immediately be saved out again, but I'm just eyeballing the
> source code. In any case, you said the performance is good; that's
> what matters :)
>
> I'm getting a segfault when I attempt to run tuxmath, and I can't nail
> it down. The fault is somewhere inside our call to png_write_info(),
> but it looks like a valid call, or at least not passing in any NULLs.
> I'm attaching my GDB session with 'tuxmath -w' and the program output
> from 'tuxmath --debug-all' in case it makes any sense to you :)
>
> @Tim: Wow! Wherever you are, it sounds fun. I guess, welcome to the
> mile-high club of free software (?)
>
> -Brendan