tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Ubuntu

[Caroline F. <car...@go...>]

On Fri, 2007-12-14 at 20:09 -0800, Bill Kendrick wrote:
> On Sat, Dec 15, 2007 at 01:53:22AM +0000, Caroline Ford wrote:
> > Ubuntu is about to release Alpha 2 for it's next long term support
> > release - Hardy Heron, due in April 08. 
> > 
> > Currently Hardy has 0.9.17 (as does Debian). I've been asked to make a
> > package of a 'daily build'. I've packaged 0.9.18's stamps but I'm
> > concerned about packaging 0.9.18 or 0.9.18+CVS. I'd say 0.9.18 was
> > unsuitable for a long term release because of the no sound bug.
> > Presuming that's fixed in cvs we've still got the >127 fonts crash bug. 
> > 
> > Are there any killer bugs fixed from 0.9.17 that it would make sense to
> > upgrade to 0.9.18+CVS?
> 
> Would it be unreasonable to have Ubuntu use the 0.9.18 that was released,
> with a patch that fixed the crash in those two magic tools when --nosound
> is being used?
> 
> Also, will there be plans to create a "tuxpaint-devel" package that
> includes only the Magic plug-in API header and "tp-magic-config" script
> and plug-in programming docs? :^) :^)
> 
We can have Ubuntu use whatever we want afaik. We just need to package
it. Routinely they get the package from Debian but Ben hasn't packaged
0.9.18 yet and they've just stopped syncing from Debian for this
release.

We'll have to package tuxpaint ourselves regardless and make a case for
it (should be easy as it's in main). 

My concern is making a package that doesn't have a fix for the >127
fonts bug, and whether this is worse or better than leaving it at
0.9.17.

I don't know how to make a tuxpaint-devel package. If someone does it
I'm sure we can argue for it to be included.

Caroline

Re: [Tuxpaint-devel] Ubuntu

[Caroline F. <car...@go...>]

On Sun, 2007-12-16 at 16:12 -0800, Bill Kendrick wrote:

> 
> SDL_pango is, unfortunately, not being used with the Text Tool at the moment.
> I still need to figure out how, if at all, that would be possible.
> I may need to use Pango directly.

It's a build dependency though, and stops 0.9.18 running on slightly
older systems such as Ubuntu dapper. What's it being used for?

Caroline

Re: [Tuxpaint-devel] Ubuntu

[Bill K. <nb...@so...>]

On Sun, Dec 16, 2007 at 02:49:01PM -0500, Albert Cahalan wrote:
> The "time" command should do for that part of the problem.
> What I was getting at is the problem of benchmarking
> something that is normally interactive and unpredictable.
> You had a playback thing... is it not working anymore?

There never WAS a playback thing.  Years ago, I had attempted to add it,
but never got it working, so it was just cruft lying around in the code
(and apparently annoying valgrind, so I finally took it out). :)


<snip>
> I would have used threads on Win32, but SDL_ttf is not
> thread-safe. Perhaps SDL_pango is thread-safe.

SDL_pango is, unfortunately, not being used with the Text Tool at the moment.
I still need to figure out how, if at all, that would be possible.
I may need to use Pango directly.


<snip> 
> I too have a job. :-/
> 
> I just got it compiled again. I'm coming up with some
> code to set X properties on the window **before** it
> gets popped up. This involves intercepting libX11 calls
> because SDL doesn't give me a normal opportunity.
> Right now it runs, but if I switch away from it then I
> can't switch back to it.

Tux Paint on the Nokia had a similar problem, I think.


> I also need to deal with paths
> and packaging.

Right on.  Thanks!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Ubuntu

[Albert C. <aca...@gm...>]

On Dec 15, 2007 1:44 AM, Bill Kendrick <nb...@so...> wrote:
> On Sat, Dec 15, 2007 at 12:01:35AM -0500, Albert Cahalan wrote:
> > On Dec 14, 2007 11:09 PM, Bill Kendrick <nb...@so...> wrote:
> >
> > > Also, will there be plans to create a "tuxpaint-devel" package that
> > > includes only the Magic plug-in API header and "tp-magic-config" script
> > > and plug-in programming docs? :^) :^)
> >
> > Is there a way to benchmark Tux Paint before this API
> > gets to be set in stone?
>
> Profiling tools, no doubt.  Perhaps simply printf()'ing timestamps.

The "time" command should do for that part of the problem.
What I was getting at is the problem of benchmarking
something that is normally interactive and unpredictable.
You had a playback thing... is it not working anymore?

> > I'm concerned about both start-up time and run-time
> > performance, especially on slower CPUs without all
> > the fancy out-of-order stuff and speculative execution.
> > You're losing a register when you make the *.so files.
> > That's normally expected to cost about 5% performance.
>
> WRT start-up time, the biggest hit I've seen is loading tons of fonts.
> (The test here, of course, is "Load System Fonts" on vs. off.)
> IIRC, I think this impacts Win32, and other platforms that aren't utilizing
> the forked font stuff.  Been a while since I looked at it closely, though.

It's no problem on Linux. Maybe the documentation
should suggest an OS upgrade for best performance.
Win32 users are used to having things slow and buggy.
Opening any file probably invokes the virus scanner,
the filesystem indexer, 42 different malware programs,
and 7 different DRM systems.

I would have used threads on Win32, but SDL_ttf is not
thread-safe. Perhaps SDL_pango is thread-safe.

(coming from the world of kernel hacking, the idea of a
library not being thread-safe beyond start-up is appalling
to me)

An alternate fix for Win32 is to call CreateProcess.
Perhaps there is a popen() that works. That would
do the job. Either invoke tuxpaint with some special
option to make it scan fonts, or just have a separate
program for that. Don't forget the locale of course.

> Speaking of relatively low-end systems, how's Tux Paint
> on the OLPC XO-1?

I too have a job. :-/

I just got it compiled again. I'm coming up with some
code to set X properties on the window **before** it
gets popped up. This involves intercepting libX11 calls
because SDL doesn't give me a normal opportunity.
Right now it runs, but if I switch away from it then I
can't switch back to it. I also need to deal with paths
and packaging.

Re: [Tuxpaint-devel] Ubuntu

[Alessandro P. <apa...@gm...>]

2007/12/15, Bill Kendrick <nb...@so...>:
> On Sat, Dec 15, 2007 at 12:01:35AM -0500, Albert Cahalan wrote:
> > On Dec 14, 2007 11:09 PM, Bill Kendrick <nb...@so...> wrote:
> >
> > > Also, will there be plans to create a "tuxpaint-devel" package that
> > > includes only the Magic plug-in API header and "tp-magic-config" script
> > > and plug-in programming docs? :^) :^)
>
> Sound good, Albert?  Speaking of relatively low-end systems, how's Tux Paint
> on the OLPC XO-1?
>

Please don't forget ARM based Linux embedded devices like the Nokia
tablets, they are wonderful devices for tuxpaint since you can
directly draw on the screen and put them in your pocket.

Unfortunately I still don't have the latest N810 so I could'nt test
the new tuxpaint release I built during the lpast days (with the new
plugins api) and hence I cannot give any advice on performance issues.

I hope I will be able to test it ASAP and I will report any issue here.


Regards.
-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] Ubuntu

[Bill K. <nb...@so...>]

On Sat, Dec 15, 2007 at 12:01:35AM -0500, Albert Cahalan wrote:
> On Dec 14, 2007 11:09 PM, Bill Kendrick <nb...@so...> wrote:
> 
> > Also, will there be plans to create a "tuxpaint-devel" package that
> > includes only the Magic plug-in API header and "tp-magic-config" script
> > and plug-in programming docs? :^) :^)
> 
> Is there a way to benchmark Tux Paint before this API
> gets to be set in stone?

Profiling tools, no doubt.  Perhaps simply printf()'ing timestamps.


> I'm concerned about both start-up time and run-time
> performance, especially on slower CPUs without all
> the fancy out-of-order stuff and speculative execution.
> You're losing a register when you make the *.so files.
> That's normally expected to cost about 5% performance.

WRT start-up time, the biggest hit I've seen is loading tons of fonts.
(The test here, of course, is "Load System Fonts" on vs. off.)
IIRC, I think this impacts Win32, and other platforms that aren't utilizing
the forked font stuff.  Been a while since I looked at it closely, though.

As always, I wish I could dedicate my full-time-attention to Tux Paint. :(
It doesn't pay the bills, though.


If it ends up causing a major impact, I'm certainly not against something
like this:  keep the API and continue using shared objects for 'most people'
(fast systems), but provide a means of compiling the Magic tools that
come with Tux Paint _into_ Tux Paint, for platforms where the performance
hit turned out to be too high.  (The tools would remain their own bits
of source, but we'd have some magic #ifdef'd code that just ends up
linking to them at build-time.)

Sound good, Albert?  Speaking of relatively low-end systems, how's Tux Paint
on the OLPC XO-1?

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Ubuntu

[Albert C. <aca...@gm...>]

On Dec 14, 2007 11:09 PM, Bill Kendrick <nb...@so...> wrote:

> Also, will there be plans to create a "tuxpaint-devel" package that
> includes only the Magic plug-in API header and "tp-magic-config" script
> and plug-in programming docs? :^) :^)

Is there a way to benchmark Tux Paint before this API
gets to be set in stone?

I'm concerned about both start-up time and run-time
performance, especially on slower CPUs without all
the fancy out-of-order stuff and speculative execution.
You're losing a register when you make the *.so files.
That's normally expected to cost about 5% performance.

Re: [Tuxpaint-devel] Ubuntu

[Bill K. <nb...@so...>]

On Sat, Dec 15, 2007 at 01:53:22AM +0000, Caroline Ford wrote:
> Ubuntu is about to release Alpha 2 for it's next long term support
> release - Hardy Heron, due in April 08. 
> 
> Currently Hardy has 0.9.17 (as does Debian). I've been asked to make a
> package of a 'daily build'. I've packaged 0.9.18's stamps but I'm
> concerned about packaging 0.9.18 or 0.9.18+CVS. I'd say 0.9.18 was
> unsuitable for a long term release because of the no sound bug.
> Presuming that's fixed in cvs we've still got the >127 fonts crash bug. 
> 
> Are there any killer bugs fixed from 0.9.17 that it would make sense to
> upgrade to 0.9.18+CVS?

Would it be unreasonable to have Ubuntu use the 0.9.18 that was released,
with a patch that fixed the crash in those two magic tools when --nosound
is being used?

Also, will there be plans to create a "tuxpaint-devel" package that
includes only the Magic plug-in API header and "tp-magic-config" script
and plug-in programming docs? :^) :^)

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

[Tuxpaint-devel] Ubuntu

[Caroline F. <car...@go...>]

Ubuntu is about to release Alpha 2 for it's next long term support
release - Hardy Heron, due in April 08. 

Currently Hardy has 0.9.17 (as does Debian). I've been asked to make a
package of a 'daily build'. I've packaged 0.9.18's stamps but I'm
concerned about packaging 0.9.18 or 0.9.18+CVS. I'd say 0.9.18 was
unsuitable for a long term release because of the no sound bug.
Presuming that's fixed in cvs we've still got the >127 fonts crash bug. 

Are there any killer bugs fixed from 0.9.17 that it would make sense to
upgrade to 0.9.18+CVS?

Caroline

[Tuxpaint-devel] Tux Paint "Magic" Tool Plug-in API presentation slides

[Bill K. <nb...@so...>]

Last night I did a talk on Tux Paint's new "Magic" tool plug-in API
at the Peninsula Linux User Group in Redwood City, California.

My presentation slides are now online, in both the original
OpenOffice.org Impress ".odp" format, as well as in Adobe ".pdf" format:

  http://tuxpaint.org/presentations/tuxpaint-magic-api.odp
  http://tuxpaint.org/presentations/tuxpaint-magic-api.pdf

Enjoy!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Bill K. <nb...@so...>]

On Thu, Dec 13, 2007 at 05:35:34PM +0100, Alessandro Pasotti wrote:
> 
> Bug filed:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1850170&group_id=66938&atid=516295

Thanks, I'll look into this as soon as I can.

-bill!

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

2007/12/12, Bill Kendrick <nb...@so...>:
> On Wed, Dec 12, 2007 at 05:39:41PM +0100, Alessandro Pasotti wrote:
> >
> > I'm complete newbie in SDL, but perhaps a good solution would be to
> > have a generic getpixel function wrapper and let this function decide
> > which getpixelXX function to call depending on the image type, is this
> > possible?
>
> That was what it was SUPPOSED to do, but I guess I botched it.
> (Usually working from on a train, usually in a hurry.)
>
> And yes, we have a bug tracker; see http://www.sf.net/projects/tuxpaint/

Bug filed:

https://sourceforge.net/tracker/index.php?func=detail&aid=1850170&group_id=66938&atid=516295


Thanks.
-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

>
> BTW I managed to make it work (quick and dirty hack):
>
> in grass.c
>
> #include "../../src/pixels.h"
>
> then adjusted magic makefile to link pixels.o

With the same hack the calligraphy tool is working too.

In this case a putpixel32 is needed in addition to getpixel32.

I'm waiting for input before committing any change.

Regards.

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Bill K. <nb...@so...>]

On Wed, Dec 12, 2007 at 05:39:41PM +0100, Alessandro Pasotti wrote:
> 
> I'm complete newbie in SDL, but perhaps a good solution would be to
> have a generic getpixel function wrapper and let this function decide
> which getpixelXX function to call depending on the image type, is this
> possible?

That was what it was SUPPOSED to do, but I guess I botched it.
(Usually working from on a train, usually in a hurry.)

And yes, we have a bug tracker; see http://www.sf.net/projects/tuxpaint/

Thanks!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

2007/12/12, Albert Cahalan <aca...@gm...>:
> On Dec 11, 2007 12:24 PM, Alessandro Pasotti <apa...@gm...> wrote:
> > 2007/12/11, Albert Cahalan <aca...@gm...>:
> > > On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:
> > >
> > > > the api passes to the plugin a getpixel function pointer chosen from
> > > > the getpixels pool with the canvas color depth, which could be
> > > > different from the color depth of the image.
> > > >
> > > > Since I'm running the test in a Xephyr maemo SDK emulator, the color
> > > > depth is probably lower than a standard true color X display.
> > >
> > > Maybe we need two getpixel functions. Maybe we need to go
> > > back to the old way, where the getpixel function looks at the
> > > surface to determine the type.
> >
> > Thanks Albert for the insight, so do you agree that we have a bug here?
>
> Sure.

Do we have a bug tracking system and should I file this bug?

[...]

> > The strange thing is that the previous version .17 is working fine on
> > this device (just a bit slow with grass tool).
>
> Probably you changed VIDEO_BPP.

No, everything is the same SDK and same color depth.

>
> Maybe VIDEO_BPP should always be 32.
> That's 8:8:8 with padding for alignment.
> Lots of things can be simplified this way.
>


BTW I managed to make it work (quick and dirty hack):

in grass.c

#include "../../src/pixels.h"

then adjusted magic makefile to link pixels.o

and used getpixel32 on grass image instead of the getpixel passed by
the plugin api.

I'm complete newbie in SDL, but perhaps a good solution would be to
have a generic getpixel function wrapper and let this function decide
which getpixelXX function to call depending on the image type, is this
possible?

What do you think?


-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Albert C. <aca...@gm...>]

On Dec 11, 2007 12:24 PM, Alessandro Pasotti <apa...@gm...> wrote:
> 2007/12/11, Albert Cahalan <aca...@gm...>:
> > On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:
> >
> > > the api passes to the plugin a getpixel function pointer chosen from
> > > the getpixels pool with the canvas color depth, which could be
> > > different from the color depth of the image.
> > >
> > > Since I'm running the test in a Xephyr maemo SDK emulator, the color
> > > depth is probably lower than a standard true color X display.
> >
> > Maybe we need two getpixel functions. Maybe we need to go
> > back to the old way, where the getpixel function looks at the
> > surface to determine the type.
>
> Thanks Albert for the insight, so do you agree that we have a bug here?

Sure.

> I'm sorry but I dont' feel skilled enough to fix this problem, I agree
> with you that low color depth is quite rare nowaday, but I'm trying to
> port tp to a Linux embedded device wich probaly has limited graphics
> capabilities.

Me too. The OLPC XO uses a 5:6:5 framebuffer. I'll probably
use 8:8:8 internally though. If I had a really fast CPU and not
much RAM, then I'd consider using 5:5:5 (not 5:6:5). I hate
that option though, because merely loading and saving an image
would reduce the colors.

> The strange thing is that the previous version .17 is working fine on
> this device (just a bit slow with grass tool).

Probably you changed VIDEO_BPP.

Maybe VIDEO_BPP should always be 32.
That's 8:8:8 with padding for alignment.
Lots of things can be simplified this way.

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

2007/12/11, Albert Cahalan <aca...@gm...>:
> On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:
>
> > the api passes to the plugin a getpixel function pointer chosen from
> > the getpixels pool with the canvas color depth, which could be
> > different from the color depth of the image.
> >
> > Since I'm running the test in a Xephyr maemo SDK emulator, the color
> > depth is probably lower than a standard true color X display.
>
> Maybe we need two getpixel functions. Maybe we need to go
> back to the old way, where the getpixel function looks at the
> surface to determine the type.

Thanks Albert for the insight, so do you agree that we have a bug here?

I'm sorry but I dont' feel skilled enough to fix this problem, I agree
with you that low color depth is quite rare nowaday, but I'm trying to
port tp to a Linux embedded device wich probaly has limited graphics
capabilities.

The strange thing is that the previous version .17 is working fine on
this device (just a bit slow with grass tool).

Can anybody help to solve this problem? I really like the grass tool
and I don't want to leave it out.

Many thanks in advance.

-- 
Alessandro Pasotti
w3:   www.itopen.it

[Tuxpaint-devel] Tux Paint programming talk this Thursday in California

[Bill K. <nb...@so...>]

I'll be speaking at the Peninsula Linux User Group ( http://www.penlug.org/ )
in Redwood City, California (just south of San Francisco) this Thursday
evening.  If you live in the area, or will be visiting, and are interested
in learning about the new 'Magic' tool plug-in API, please join us!
(It's free)

Otherwise, I'll be posting my slides (includes example code) on the
Tux Paint website after the talk takes place.

As always, Tux Paint-related events (both upcoming, and past) are listed on:

  http://www.tuxpaint.org/events/

If you have any kind of Tux Paint-related event (e.g., I recently learned
of an art contest in Germany that will utilize Tux Paint, and am waiting
to hear whether I can post the details online), do let me know so I can
post it to that page.

Thanks and enjoy!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] some more investigation on grass plugin

[Albert C. <aca...@gm...>]

On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote:

> the api passes to the plugin a getpixel function pointer chosen from
> the getpixels pool with the canvas color depth, which could be
> different from the color depth of the image.
>
> Since I'm running the test in a Xephyr maemo SDK emulator, the color
> depth is probably lower than a standard true color X display.

Maybe we need two getpixel functions. Maybe we need to go
back to the old way, where the getpixel function looks at the
surface to determine the type. The decision could be made with
an array of function pointers or with if..else; best performance
will depend on the CPU. Some things to consider are:

If the user data is not kept as 8:8:8, it will get mangled when
the drawings are opened and saved. Mangling data is rude.

Keeping data in 8:8:8 format requires more memory.

We need 8:8:8 when we want to add an alpha channel.
(it is of course 8:8:8:8 then) We thus can not escape
dealing with this format, even if we wish to.

Working with 8:8:8 data is generally fast. This is because
the CPU can address individual bytes, but can not address
the components of a 5:5:5 or 5:6:5 pixel.

A rapidly declining number of systems use a display depth
that is not 8:8:8.

We can not avoid color problem if we use 5:6:5. There are
operations, such as blur, that will tend to make things turn
purple or green if the number of bits is not balanced.

For internal use, 16:16:16 has some advantages. It can hold
8:8:8 sRGB while being linear. This would let us avoid conversion
to float in various places.

Re: [Tuxpaint-devel] floating point exception with certain (wrong?) svg

[Pere P. i C. <pe...@fo...>]

On Mon, 2007-12-10 at 14:56 -0800, Bill Kendrick wrote:

> Sounds like the SVG libs we use don't like it.  Is this using the new
> libRSVG stuff, or the old SVG+cairo stuff?  (normal vs 'oldsvg' build target
> to "make")

It's a normal build.

> 
> FWIW, Mozilla Seamonkey on WinXP does not crash.
> 
I've had a crash with tuxpaint+openclipart svgs under WXP, but had no
time to investigate, not sure if the same file will produce the same
crash under windows.

> Thx!
> 
> -bill!

Yours
Pere

Re: [Tuxpaint-devel] floating point exception with certain (wrong?) svg

[Bill K. <nb...@so...>]

On Mon, Dec 10, 2007 at 11:40:26PM +0100, Pere Pujal i Carabantes wrote:
> Hi all!
> 
> Last week I've discovered the openclipart collection www.openclipart.org
> it is packaged at least for debian and ubuntu.
> 
> At least one of the svg that comes with the debian package  is able to
> crash tuxpaint, it is not attached as it crashes evolution as well, so
> maybe it is not a tuxpaint-specific problem but I had mostly of this
> email writed when evolution crashed, so I send anyway.

Sounds like the SVG libs we use don't like it.  Is this using the new
libRSVG stuff, or the old SVG+cairo stuff?  (normal vs 'oldsvg' build target
to "make")

FWIW, Mozilla Seamonkey on WinXP does not crash.

Thx!

-bill!

[Tuxpaint-devel] floating point exception with certain (wrong?) svg

[Pere P. i C. <pe...@fo...>]

Hi all!

Last week I've discovered the openclipart collection www.openclipart.org
it is packaged at least for debian and ubuntu.

At least one of the svg that comes with the debian package  is able to
crash tuxpaint, it is not attached as it crashes evolution as well, so
maybe it is not a tuxpaint-specific problem but I had mostly of this
email writed when evolution crashed, so I send anyway.

You can download from
http://fornol.no-ip.org/linux/tuxpaint/stamps/perspectival_house_01.svg
or if you have openclipart-svg installed, you can find it
at /usr/[local]/share/openclipart/svg/buildings/perspectival_house_01.svg

Inkscape and sodipodi displays it, gimp is unable to open it and
Imagemagick displays it but complainins the following 
display: unable to open image `pattern3182': No such file or directory.

 Resaving it under inkscape or sodipodi does not arrange it, repainting
it and saving lets tuxpaint not crashing.

Plain bash error is "floating point exception".

valgrind --tool=memcheck --num-callers=50 --leak-check=yes tuxpaint
--nosound --640x480 says this just after the crash:

==10858== 
==10858== Process terminating with default action of signal 8 (SIGFPE)
==10858==  Integer divide by zero at address 0x630A8F35
==10858==    at 0x42365C7: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x4233DAB: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x42252E5: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41E9793: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41F3B4A: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41F71D7: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41F61F3: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41F6CBE: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41F7100: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41F4717: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41E7282: (within /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41DFE7B: cairo_fill_preserve
(in /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41DFEA1: cairo_fill (in /usr/lib/libcairo.so.2.11.5)
==10858==    by 0x41D2181: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41CCBBD: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41C1F4A: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41C491D: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41C4B79: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41C491D: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41C5419: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41C491D: (within /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41D2A3D: rsvg_handle_render_cairo_sub
(in /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x41D2B6B: rsvg_handle_render_cairo
(in /usr/lib/librsvg-2.so.2.18.2)
==10858==    by 0x8055944: load_svg (tuxpaint.c:16390)
==10858==    by 0x8055B1B: do_loadimage (tuxpaint.c:7902)
==10858==    by 0x8060737: get_stamp_thumb (tuxpaint.c:5747)
==10858==    by 0x80611A4: draw_stamps (tuxpaint.c:8609)
==10858==    by 0x8065389: mainloop (tuxpaint.c:2792)
==10858==    by 0x8068C76: main (tuxpaint.c:1774)
==10858== 
==10858== ERROR SUMMARY: 640 errors from 47 contexts (suppressed: 0 from
0)
==10858== malloc/free: in use at exit: 18,850,450 bytes in 15,945
blocks.
==10858== malloc/free: 260,564 allocs, 244,619 frees, 152,723,859 bytes
allocated.
==10858== For counts of detected errors, rerun with: -v
==10858== searching for pointers to 15,945 not-freed blocks.
==10858== checked 27,989,464 bytes.
==10858== 
==10858== 

If you want the full valgrind output, just say it.

Hope this helps
Pere

[Tuxpaint-devel] some more investigation on grass plugin

[Alessandro P. <apa...@gm...>]

Hi,

I'm still having problem but maybe I've found where to look for errors.

I seems like the function getpixel() return wrong values.

If I've got it right, the plugin reads a rgba pixel value from
grass_data.png, then applies some transformations on that value and
draws the new pixel on the canvas.

I put some printf in the code

printf("Getpixel %d %d img_grass rgba : %d %d %d %d\n", xx + src.x, yy
+ src.y, r, g, b, a);

and I see this output (alternatively):

Getpixel 124 63 img_grass rgba : 82 180 0 0
Getpixel 125 63 img_grass rgba : 17 0 0 0

the pixel values in the image have a fixed rgb and a variable alpha
channel, the bytes are hence

82 180 17 xx

where xx is the alpha and changes from 0% to 100% among the image.

Perhaps the problem is the following:

the api passes to the plugin a getpixel function pointer chosen from
the getpixels pool with the canvas color depth, which could be
different from the color depth of the image.

Since I'm running the test in a Xephyr maemo SDK emulator, the color
depth is probably lower than a standard true color X display.

Any comment?

-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] grass and calligraphy magic tools not working on the nokia tablets

[Alessandro P. <apa...@gm...>]

Update: I've enabled svg and cairo but the problem remains: still no
effect (beside sound) while drawing with the grass tool.

Seems like the magic tools code significantly chaged from 0.9.17 (my
previous build) to the current CVS.

I really don't know where to start in order to fix this.

Console output don't show anything useful.


2007/12/10, Alessandro Pasotti <apa...@gm...>:
> Hello,
>
> I'm testing a new build for the N810 tablets, it is based on current
> CVS (I guess it should be 0.9.19).
>
> The a.m. tools do not work: I can select them and hear the sound while
> drawing but nothing happens.
>
> The compile flag is NOKIA_770 and several features are disabled:
>
>
> nokia770:
>         make \
>                 DATA_PREFIX=/usr/share/tuxpaint \
>                 SVG_LIB= SVG_CFLAGS= NOSVGFLAG=NOSVG \
>                 MAEMOFLAG=NOKIA_770 \
>                 LOCALE_PREFIX=$(PREFIX)/share/locale \
>                 CONFDIR=/etc/tuxpaint \
>                 NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB= \
>                 ARCH_LIBS= \
>                 PAPER_LIB=
>
> Perhaps those tools need SVG or PANGO?
>
> In my previous package, based on 0.16 the grass tool worked fine (just
> a little bit slow).
>
>
> Any hint about how to fix it?
>
> I'm still testing the package on i386 in the SDK, I've not yet built
> it for armel.
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>


-- 
Alessandro Pasotti
w3:   www.itopen.it

[Tuxpaint-devel] grass and calligraphy magic tools not working on the nokia tablets

[Alessandro P. <apa...@gm...>]

Hello,

I'm testing a new build for the N810 tablets, it is based on current
CVS (I guess it should be 0.9.19).

The a.m. tools do not work: I can select them and hear the sound while
drawing but nothing happens.

The compile flag is NOKIA_770 and several features are disabled:


nokia770:
	make \
		DATA_PREFIX=/usr/share/tuxpaint \
		SVG_LIB= SVG_CFLAGS= NOSVGFLAG=NOSVG \
		MAEMOFLAG=NOKIA_770 \
		LOCALE_PREFIX=$(PREFIX)/share/locale \
		CONFDIR=/etc/tuxpaint \
		NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB= \
		ARCH_LIBS= \
		PAPER_LIB=

Perhaps those tools need SVG or PANGO?

In my previous package, based on 0.16 the grass tool worked fine (just
a little bit slow).


Any hint about how to fix it?

I'm still testing the package on i386 in the SDK, I've not yet built
it for armel.

-- 
Alessandro Pasotti
w3:   www.itopen.it