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.