Thread: [Tuxpaint-devel] Sysfonts by default?
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Bill K. <nb...@so...> - 2009-10-10 05:56:43
|
Does Tux Paint seem to be stable for people when using the "--sysfonts" option? Should we enable it by default? -- -bill! Sent from my computer |
From: Karl O. H. <ka...@hu...> - 2009-11-06 22:32:50
|
Laurdag 10. oktober 2009 skreiv Bill Kendrick: >Does Tux Paint seem to be stable for people when using the "--sysfonts" >option? Should we enable it by default? It doesn’t crash for me anymore. But Tux Paint takes ages to start when I enable it. And I don’t even have many fonts installed. -- Karl Ove Hufthammer http://huftis.org/ Jabber: ka...@hu... |
From: Bill K. <nb...@so...> - 2009-11-06 22:36:24
|
On Fri, Nov 06, 2009 at 11:32:27PM +0100, Karl Ove Hufthammer wrote: > Laurdag 10. oktober 2009 skreiv Bill Kendrick: > >Does Tux Paint seem to be stable for people when using the "--sysfonts" > >option? Should we enable it by default? > > It doesn???t crash for me anymore. But Tux Paint takes ages to start when I > enable it. And I don???t even have many fonts installed. > What platform? -- -bill! Sent from my computer |
From: Karl O. H. <ka...@hu...> - 2009-11-06 22:50:09
|
Fredag 6. november 2009 skreiv Bill Kendrick: >> It doesn???t crash for me anymore. But Tux Paint takes ages to start when >> I enable it. And I don???t even have many fonts installed. > >What platform? Mandriva Linux 2010.0. Latest CVS version of Tux Paint. -- Karl Ove Hufthammer http://huftis.org/ Jabber: ka...@hu... |
From: Bill K. <nb...@so...> - 2009-11-06 23:14:04
|
On Fri, Nov 06, 2009 at 11:49:49PM +0100, Karl Ove Hufthammer wrote: > Fredag 6. november 2009 skreiv Bill Kendrick: > >> It doesn???t crash for me anymore. But Tux Paint takes ages to start when > >> I enable it. And I don???t even have many fonts installed. > > > >What platform? > > Mandriva Linux 2010.0. Latest CVS version of Tux Paint. Hrm, and when you run tuxpaint --verbose-version do you see: Threaded font loader enabled (FORKED_FONTS) I do, but I also get quite a bit of delay prior to being able to draw. (And if I move away from, then back to, the Tux Paint window, the majority of the screen doesn't update... just the "busy bar" at the bottom.) Right now I'm too busy, and brain too fried, to figure out the difference (e.g., if you change from forked to SDL thread-based, in fonts.h). Albert, are you out there? Can you talk about the state of all this stuff? (Right now, it looks like "FORKED_FONTS" is used, unless we're running on Win32, BeOS or Mac OS X. -bill! |
From: Albert C. <al...@us...> - 2009-11-07 03:41:00
|
On Fri, Nov 6, 2009 at 6:13 PM, Bill Kendrick <nb...@so...> wrote: > On Fri, Nov 06, 2009 at 11:49:49PM +0100, Karl Ove Hufthammer wrote: >> Fredag 6. november 2009 skreiv Bill Kendrick: >>>> It doesn???t crash for me anymore. But Tux Paint takes ages to start when >>>> I enable it. And I don???t even have many fonts installed. >>> >>>What platform? >> >> Mandriva Linux 2010.0. Latest CVS version of Tux Paint. This is odd. You shouldn't notice any slowness unless you immediately switch to the text tool. Everything else should be perfectly usable. I suppose it might be good to lower the IO priority, in case excessive disk access is the problem. What does "top" say about this, in CPU the percentages line up top? > Threaded font loader enabled (FORKED_FONTS) > > > I do, but I also get quite a bit of delay prior to being able to draw. > (And if I move away from, then back to, the Tux Paint window, the > majority of the screen doesn't update... just the "busy bar" at the bottom.) Does "draw" mean the paint tool, or did you rapidly switch to the text tool? > Right now I'm too busy, and brain too fried, to figure out the difference > (e.g., if you change from forked to SDL thread-based, in fonts.h). > > Albert, are you out there? Can you talk about the state of all this stuff? > (Right now, it looks like "FORKED_FONTS" is used, unless we're running > on Win32, BeOS or Mac OS X. Threads would be great on all platforms, but SDL is not thread-safe!!! I seem to recall that Bill changed the font library though, from SDLttf to SDLPango, so maybe that isn't a problem anymore. While it is possible to fork in Windows, Win32 will fail if you do so. Thus, without threads, Windows loses out. Forking should work fine everywhere else. |
From: Bill K. <nb...@so...> - 2009-11-07 04:44:18
|
On Fri, Nov 06, 2009 at 10:40:49PM -0500, Albert Cahalan wrote: > Does "draw" mean the paint tool, or did you rapidly switch > to the text tool? Emtpy grey buttons in the toolbar, selector and color chooser parts of the screen appear. Part of the title screen remains visible where the drawing canvas goes. The yellow/black animated busy bar spins at the bottom. <snip> > Threads would be great on all platforms, but SDL is not thread-safe!!! > I seem to recall that Bill changed the font library though, from SDLttf > to SDLPango, so maybe that isn't a problem anymore. SDL_Pango is used for the UI (button labels, dialogs, Tux text), while SDL_ttf is used for the Text tool (so that we can let the user pick a font -- something the pango system doesn't make readily available, if I recall.) > While it is possible to fork in Windows, Win32 will fail if you do so. > Thus, without threads, Windows loses out. > > Forking should work fine everywhere else. Well, can you look and see if I or someone else broke something? :) Thanks, -- -bill! Sent from my computer |
From: Karl O. H. <ka...@hu...> - 2009-11-09 19:02:53
|
Laurdag 7. november 2009 skreiv Bill Kendrick: >Hrm, and when you run tuxpaint --verbose-version do you see: > > Threaded font loader enabled (FORKED_FONTS) Yes. When I start the program, it shows and the splash screen with the busy bar at the bottom. When that is finished (a few seconds), empty UI buttons are shown, and the busy bar reappears. The splash screen image is shown in the background. It then takes a long time for the program to show the actual buttons and canvas. -- Karl Ove Hufthammer http://huftis.org/ Jabber: ka...@hu... |
From: Albert C. <aca...@gm...> - 2009-11-09 19:29:45
|
On Mon, Nov 9, 2009 at 2:02 PM, Karl Ove Hufthammer <ka...@hu...> wrote: > When I start the program, it shows and the splash screen with the busy bar at > the bottom. When that is finished (a few seconds), empty UI buttons are shown, > and the busy bar reappears. The splash screen image is shown in the > background. It then takes a long time for the program to show the actual > buttons and canvas. I built Tux Paint from CVS, and I do see this. Somebody serialized the whole thing! The whole point of the font scanning task is to do things in the background while the user gets to start painting. It's supposed to be asynchronous. It should start as early as possible, and not be looked at until needed by the text tool. I think that one of two additions broke things: a. modular text tool b. labels Right now, Tux Paint stops to wait for the font scanner to complete before displaying the canvas. No!!!!! It's supposed to keep running. It's a background task that could take a long time. There is no point to starting a background task if you're just going to wait for it to finish. Additionally, quality was degraded by having the task start up after the setup function. This change was needed so that locales would be set up for font testing. Unfortunately, the setup function includes all sorts of really slow code. It does things like loading UI images. Yesterday I started to break up the setup function to help with this. I moved the command line and config file parsing out and unified them. It needs more work. I'll probably use gperf to get O(args) parsing in place of the O(args*possible) parsing we have now. There are some oddities that I hope to fix next weekend, like help=yes and nohelp=no being accepted in the config file. BTW, there are two ways to use gperf. It can generate it's output (a *.c file) during the build, or it can be run by hand and the result being checked in. I see arguments for both ways. |
From: Pere P. i C. <pe...@fo...> - 2009-11-10 17:50:25
|
El dl 09 de 11 de 2009 a les 14:29 -0500, en/na Albert Cahalan va escriure: > Somebody serialized the whole thing! The whole point of the font > scanning task is to do things in the background while the user > gets to start painting. It's supposed to be asynchronous. It should > start as early as possible, and not be looked at until needed by > the text tool. > > I think that one of two additions broke things: > > a. modular text tool > b. labels > It was labels. Earlier label code was needing fonts to render the saved labels at startup. http://code.google.com/p/tuxpaint-text/source/list Now fonts are no more needed at startup as labels are rendered from saved surfaces, I had not realized the implications of loading fonts at startup, so I left as it was :( |
From: Albert C. <al...@us...> - 2009-11-10 19:32:36
|
n Tue, Nov 10, 2009 at 12:50 PM, Pere Pujal i Carabantes <pe...@fo...> wrote: > It was labels. Earlier label code was needing fonts to render the saved > labels at startup. > http://code.google.com/p/tuxpaint-text/source/list > > Now fonts are no more needed at startup as labels are rendered from > saved surfaces, I had not realized the implications of loading fonts at > startup, so I left as it was :( This seems to show that code was added/copied, not moved: http://code.google.com/p/tuxpaint-text/source/detail?r=15 Correct? So fixing things is as simple as just removing that chunk of code now and it won't break labels? |
From: Pere P. i C. <pe...@fo...> - 2009-11-10 21:24:31
|
El dt 10 de 11 de 2009 a les 14:32 -0500, en/na Albert Cahalan va escriure: > n Tue, Nov 10, 2009 at 12:50 PM, Pere Pujal i Carabantes > <pe...@fo...> wrote: > > > It was labels. Earlier label code was needing fonts to render the saved > > labels at startup. > > http://code.google.com/p/tuxpaint-text/source/list > > > > Now fonts are no more needed at startup as labels are rendered from > > saved surfaces, I had not realized the implications of loading fonts at > > startup, so I left as it was :( > > This seems to show that code was added/copied, not moved: > http://code.google.com/p/tuxpaint-text/source/detail?r=15 > > Correct? So fixing things is as simple as just removing that chunk > of code now and it won't break labels? It will break the font recognition at load_info_about_label_surface(). Since the font info will not be used until editing the label, I think I will be able to pass this part of code to some other place where it will be runned after the fonts are loaded. So no problems here. |
From: Bill K. <nb...@so...> - 2009-11-10 21:59:17
|
On Tue, Nov 10, 2009 at 10:24:04PM +0100, Pere Pujal i Carabantes wrote: > It will break the font recognition at load_info_about_label_surface(). > Since the font info will not be used until editing the label, I think I > will be able to pass this part of code to some other place where it will > be runned after the fonts are loaded. > So no problems here. Thank you, Pere and Albert. Please let me know if you need a hand doing 'surgery' to get things working nicely again. (No guarantee I'll have time or skills for it, but I can at least try to pretend to manage, or something. ;) ) -bill! |
From: Pere P. i C. <pe...@fo...> - 2009-11-11 22:25:42
|
El dt 10 de 11 de 2009 a les 13:59 -0800, en/na Bill Kendrick va escriure: > On Tue, Nov 10, 2009 at 10:24:04PM +0100, Pere Pujal i Carabantes wrote: > > It will break the font recognition at load_info_about_label_surface(). > > Since the font info will not be used until editing the label, I think I > > will be able to pass this part of code to some other place where it will > > be runned after the fonts are loaded. > Thank you, Pere and Albert. Please let me know if you need a hand doing > 'surgery' to get things working nicely again. (No guarantee I'll have time > or skills for it, but I can at least try to pretend to manage, or > something. ;) ) I've just commited those changes, can you or somebody else check if there are not side issues? Thanks Pere |
From: Bill K. <nb...@so...> - 2009-11-11 22:32:07
|
On Wed, Nov 11, 2009 at 11:09:03PM +0100, Pere Pujal i Carabantes wrote: > I've just commited those changes, can you or somebody else check if > there are not side issues? In other news, "tuxpaint --sysfonts" is working better, now. (I am not forced to wait unless I go to the "Text" tool soon after launching; the rest of the app is available immediately). I did not do thorough testing of the new Label feature/etc. Very busy working right now. :( (And getting increasingly grumpy, sorry.) -bill! |
From: Bill K. <nb...@so...> - 2009-11-11 22:28:30
|
On Wed, Nov 11, 2009 at 11:09:03PM +0100, Pere Pujal i Carabantes wrote: > I've just commited those changes, can you or somebody else check if > there are not side issues? Uh... Albert? Where the hell did my "-w" command-line option go!?!? <:^( -bill! |
From: Albert C. <al...@us...> - 2009-11-12 10:21:02
|
On Wed, Nov 11, 2009 at 5:28 PM, Bill Kendrick <nb...@so...> wrote: > On Wed, Nov 11, 2009 at 11:09:03PM +0100, Pere Pujal i Carabantes wrote: >> I've just commited those changes, can you or somebody else check if >> there are not side issues? > > Uh... Albert? Where the hell did my "-w" command-line option go!?!? <:^( I'm not done fixing up the command-line parser. I got it mostly working last weekend. Probably I can finish it this weekend. BTW, I figured nobody would use the undocumented options. |