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/