Thread: [Tuxpaint-devel] Ubuntu
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Caroline F. <car...@go...> - 2007-12-15 01:49:01
|
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 |
From: Bill K. <nb...@so...> - 2007-12-15 04:09:49
|
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/ |
From: Albert C. <aca...@gm...> - 2007-12-15 05:01:36
|
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. |
From: Bill K. <nb...@so...> - 2007-12-15 06:44:21
|
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/ |
From: Alessandro P. <apa...@gm...> - 2007-12-15 10:06:28
|
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 |
From: Albert C. <aca...@gm...> - 2007-12-16 19:49:02
|
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. |
From: Bill K. <nb...@so...> - 2007-12-17 00:12:17
|
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/ |
From: Caroline F. <car...@go...> - 2007-12-17 00:21:43
|
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 |
From: Bill K. <nb...@so...> - 2007-12-17 16:38:26
|
On Mon, Dec 17, 2007 at 12:29:39AM +0000, Caroline Ford wrote: > 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? SDL_pango is being used to render the UI text (prompts, button labels, etc.) SDL_ttf was simply not robust enough to handle the more complex languages, like Telugu or Arabic. You can build _without_ Pango, though. Shin-Ichi did this for older Fedoras. John is going to do it for older Windowses. Check INSTALL.txt. :) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: Caroline F. <car...@go...> - 2007-12-17 00:51:02
|
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 |
From: Bill K. <nb...@so...> - 2007-12-17 16:44:07
|
On Mon, Dec 17, 2007 at 12:59:07AM +0000, Caroline Ford wrote: > 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'm not 100% certain, but I'm pretty sure the bug's been around longer than just 0.9.18. :) Additionally, this affects people when "Use System Fonts" is enabled, and we actually say, in Tux Paint Config's GUI, that this option may cause instability. > 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. I think all we need out of it is: Config script (similar to sdl-config, gtk-config, etc.): /usr/bin/tp-magic-config Man page: /usr/share/man/man1/tp-magic-config.1.gz API header file: /usr/include/tuxpaint/tp_magic_api.h Documentation (directory): /usr/share/doc/tuxpaint-dev/ Dependency-wise, we obviously recommend 'tuxpaint', and we require 'libsdl-dev' and 'libsdl-mixer1.2-dev', and I think that's it. (Based on what tp_magic_api.h #includes.) Ben, you around? -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: Caroline F. <car...@go...> - 2007-12-18 23:32:08
|
On Mon, 2007-12-17 at 08:44 -0800, Bill Kendrick wrote: > On Mon, Dec 17, 2007 at 12:59:07AM +0000, Caroline Ford wrote: > > 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'm not 100% certain, but I'm pretty sure the bug's been around longer > than just 0.9.18. :) Additionally, this affects people when "Use System Fonts" > is enabled, and we actually say, in Tux Paint Config's GUI, that this option > may cause instability. So this doesn't affect normal installs? In Ubuntu-land -config is in universe (ie an extra optional thing to install) and tuxpaint proper is in main (because it is installed by default in Edubuntu). This means that the vast majority of users won't touch or install -config. If normal user installing Edubuntu from the CD isn't affected then I don't think I care that much. I've emailed the Ubuntu-devel-discuss mailing list to ask them what they think. Caroline |
From: Bill K. <nb...@so...> - 2007-12-30 19:29:13
|
On Tue, Dec 18, 2007 at 11:46:18PM +0000, Caroline Ford wrote: > In Ubuntu-land -config is in universe (ie an extra optional thing to > install) and tuxpaint proper is in main (because it is installed by > default in Edubuntu). This means that the vast majority of users won't > touch or install -config. BTW, FWIW, the main Tux Paint manpage mentions that --sysfonts can "cause trouble." -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |