From: Andrew R. <aro...@ya...> - 2009-01-19 12:54:14
|
>I've pinned down the problem, but I'm not quite sure why the code is >written the way it is. > >The problem arises in src/plfreetype.c in FT_PlotChar. There are two >different code paths depending on whether the pixel mode is mono (i.e. >no anti-aliasing) or not. However, the first path is also taken if icol0 >= 0, i.e. the background colour. I can't quite see the logic for this. >Normally is is not a problem since you wouldn't display text in the >background colour. Example 24 however plots 4 coloured bands so you >can't see the background, then switches to the background colour to >print the text. The crazy fonts arise because the code assumes a mono >font - i.e. each pixel is represented by one bit. This is not the case >for the anti-aliased text in the background colour. I've just commented >out this special case for icol0 = 0. I don't quite see why it was >there in the first place. This fixes example 24. Perhaps someone better >familiar with the freetype code could say why this was done originally? My recollection, late at night and a few years down the track, is that with the "original anti-aliasing technique" (i.e. not the "BLENDED ANTIALIASING" which 24bit supports, but the ugly anti-aliasing which also works with 8bit), when the text colour had an index of "0", there were either infrequent division by zero errors or some distracting psychedelic anti-aliasing effects/artifacts. I can not remember which for sure, but regardless dropping background coloured text back to non-antialiasing was the quick way to fix the problem which had minimal impact since drawing text with the background colour was virtually never done. In short, it was a quick "design compromise" to fit the original simplistic code used for anti-alaising when working with limited colours like 8 bit palettes used by GIFs or the lower-resolution drivers of the day. -Andrew |
From: Werner S. <sm...@ia...> - 2009-01-20 15:53:03
|
Hi Andrew, > wxwidgets works fine for me on Linux using e.g. > > ./x24c -dev wxwidgets > > but I don't think I am getting the freetype backend since the fonts > all > work fine. If you don't have the AGG library installed, then you use the basic backend here which by default uses it's own text processing routines and not freetype. > > > The message you are getting occurs when freetype is initialised. > This is > before any text plotting occurs and so shouldn't be as a result of my > recent changes. If you force freetype but no anti-aliasing, i.e. > > ./x24c -dev wxwidgets -drvopt smooth=0,freetype=1,text=0 > > then things break. Problem is in the logic in the driver code. It's > different to gd.c. If you set smooth=0 then it will always fail with > the > message you have got. I've fixed this in svn. Can you try again? Ah, sorry. Actually I initialized smooth_text=-1 (although this should be 1) in my last changes. My bad. But due this you found a bug in the driver ;). Very well! So, sorry for the noise, it works now again also on Windows. Thanks, Werner > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2009-01-20 16:04:32
|
On Tue, Jan 20, 2009 at 04:52:56PM +0100, Werner Smekal wrote: > Hi Andrew, > > >wxwidgets works fine for me on Linux using e.g. > > > >./x24c -dev wxwidgets > > > >but I don't think I am getting the freetype backend since the fonts > >all > >work fine. > > If you don't have the AGG library installed, then you use the basic > backend here which by default uses it's own text processing routines > and not freetype. > > > > > >The message you are getting occurs when freetype is initialised. > >This is > >before any text plotting occurs and so shouldn't be as a result of my > >recent changes. If you force freetype but no anti-aliasing, i.e. > > > >./x24c -dev wxwidgets -drvopt smooth=0,freetype=1,text=0 > > > >then things break. Problem is in the logic in the driver code. It's > >different to gd.c. If you set smooth=0 then it will always fail with > >the > >message you have got. I've fixed this in svn. Can you try again? > > Ah, sorry. Actually I initialized smooth_text=-1 (although this should > be 1) in my last changes. My bad. But due this you found a bug in the > driver ;). Very well! > > So, sorry for the noise, it works now again also on Windows. Excellent! Since the basic font handling is good, obviously the freetype enabled but anti-aliasing disabled case is not widely used! Actually as a result I've realised how good the fonts are in the wxwidget driver. I'm tempted to switch from xwin. Glad it all works again now. Andrew |
From: Alan W. I. <ir...@be...> - 2009-01-20 20:27:38
|
On 2009-01-20 16:04-0000 Andrew Ross wrote: > Excellent! Since the basic font handling is good, obviously the freetype > enabled but anti-aliasing disabled case is not widely used! Actually as > a result I've realised how good the fonts are in the wxwidget driver. > I'm tempted to switch from xwin. Same here. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2009-01-20 19:08:55
|
On 2009-01-20 16:52+0100 Werner Smekal wrote: > Ah, sorry. Actually I initialized smooth_text=-1 (although this should > be 1) in my last changes. My bad. But due this you found a bug in the > driver ;). Very well! > > So, sorry for the noise, it works now again also on Windows. Hi Werner: I have a segfault to report for wxwidgets on Linux for narrowly defined circumstances, but first the good news. I confirm on my Debian testing platform that for revision 9358 ( TTFDIR=/usr/share/fonts/truetype ; PLPLOT_FREETYPE_SANS_FONT=$TTFDIR/arphic/bkai00mp.ttf PLPLOT_FREETYPE_SERIF_FONT=$TTFDIR/freefont/FreeSerif.ttf PLPLOT_FREETYPE_MONO_FONT=$TTFDIR/ttf-devanagari-fonts/lohit_hi.ttf PLPLOT_FREETYPE_SCRIPT_FONT=$TTFDIR/unfonts/UnBatang.ttf PLPLOT_FREETYPE_SYMBOL_FONT=$TTFDIR/ttf-bengali-fonts/JamrulNormal.ttf c/x24c -dev wxwidgets -drvopt smooth=0,freetype=1,text=0) gives pretty good (slightly ragged looking letters) results for the AGG backend. If I drop all the -drvopt stuff (which I believe is the same as smooth=1, freetype=1, and text=1), the results look outstanding. It's great that the default looks so good now (assuming the user has installed libAGG). No segfaults were encountered for example 24 or any other single-stream example. However, for example 14 I have evidence that the windows events from the two streams are getting confused, and I also get a segfault for that example for a particular narrow pattern of use. Here are the details for example 14. If I run the example the usual two windows are displayed (master and slave). If I hit return when the slave is in focus or the master in focus, both plot windows move on to the next page. If I hit return again in either master or slave, the process smoothly terminates. Note, this behaviour is different then -dev xwin where a hit of return is ignored if it is done with the slave window in focus. That's consistent with the idea that the slave should not affect the master. The wxwidgets issue of the slave being in control of the master could just be a minor side issue, but I think it is consistent with the idea that the wxwidgets device is confusing windows events from the two separate streams which is a much more serious issue. There are five other (besides hitting return) possible methods for terminating the window. There are two window manager controls for doing it and the corresponding alt-F4 and the wxwidgets file button for exit and the corresponding alt-x. If I use any of those 5 methods when the slave is in focus, I get the "Program aborted" message. If I use any of those 5 methods when the master is in focus, I get a segfault. Again, this is consistent with the idea that the wxwidgets device is confusing windows events from the two separate streams. I assume the fix is to change some variables in the wxwidgets device code to be stored in a stream-dependent way similar to changes we have made in other devices recently to deal with example 14. The "hit return" termination method and the 5 other termination methods all work fine for the single-stream examples. Some comments on wxPLplotDemo. * The "hit return" method does nothing. Perhaps that should be changed to be consistent with -dev wxwidgets * The 5 other termination methods terminate silently without the "Program aborted" message (but also without a segfault). I am not sure whether you want to be consistent with -dev wxwidgets here in generating the message. Your call. * Could you change wxPLplotDemo to put the backend name in the title (like you do for -dev wxwidgets)? * From the way the result looks, it appears it is using the default backend rather than AGG. Could you change it to the same great defaults that occur for -dev wxwidgets? * There are some funny discontinuities in the sinc curve displayed by wxPLplotDemo compared to the nice smooth results in example 1. That may simply be the result of using the default backend or it may be an additional issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2009-01-23 19:54:34
|
Hi Alan and others, I added a Todo page to our wiki here: http://www.miscdebris.net/plplot_wiki/index.php?title=Todo_List since I have troubles to remember what bugs/features I should fix/add ;) We actually have the sourceforge bugs/features pages but it's just to cumbersome to use just to keep track what is on the developers todo list. Anybody is welcome to use this list as well. It's also good to know what the developers are just working on. Regards, Werner On Tue, 2009-01-20 at 11:08 -0800, Alan W. Irwin wrote: > On 2009-01-20 16:52+0100 Werner Smekal wrote: > > > Ah, sorry. Actually I initialized smooth_text=-1 (although this should > > be 1) in my last changes. My bad. But due this you found a bug in the > > driver ;). Very well! > > > > So, sorry for the noise, it works now again also on Windows. > > Hi Werner: > > I have a segfault to report for wxwidgets on Linux for narrowly defined > circumstances, but first the good news. > > I confirm on my Debian testing platform that for revision 9358 > > ( TTFDIR=/usr/share/fonts/truetype ; > PLPLOT_FREETYPE_SANS_FONT=$TTFDIR/arphic/bkai00mp.ttf > PLPLOT_FREETYPE_SERIF_FONT=$TTFDIR/freefont/FreeSerif.ttf > PLPLOT_FREETYPE_MONO_FONT=$TTFDIR/ttf-devanagari-fonts/lohit_hi.ttf > PLPLOT_FREETYPE_SCRIPT_FONT=$TTFDIR/unfonts/UnBatang.ttf > PLPLOT_FREETYPE_SYMBOL_FONT=$TTFDIR/ttf-bengali-fonts/JamrulNormal.ttf > c/x24c -dev wxwidgets -drvopt smooth=0,freetype=1,text=0) > > gives pretty good (slightly ragged looking letters) results for the AGG > backend. If I drop all the -drvopt stuff (which I believe is the same as > smooth=1, freetype=1, and text=1), the results look outstanding. It's great > that the default looks so good now (assuming the user has installed > libAGG). > > No segfaults were encountered for example 24 or any other single-stream > example. However, for example 14 I have evidence that the windows events > from the two streams are getting confused, and I also get a segfault for > that example for a particular narrow pattern of use. > > Here are the details for example 14. If I run the example the usual two > windows are displayed (master and slave). If I hit return when the slave is > in focus or the master in focus, both plot windows move on to the next page. > If I hit return again in either master or slave, the process smoothly > terminates. Note, this behaviour is different then -dev xwin where a hit of > return is ignored if it is done with the slave window in focus. That's > consistent with the idea that the slave should not affect the master. The > wxwidgets issue of the slave being in control of the master could just be a > minor side issue, but I think it is consistent with the idea that the > wxwidgets device is confusing windows events from the two separate streams > which is a much more serious issue. > > There are five other (besides hitting return) possible methods for > terminating the window. There are two window manager controls for doing it > and the corresponding alt-F4 and the wxwidgets file button for exit and the > corresponding alt-x. If I use any of those 5 methods when the slave is in > focus, I get the "Program aborted" message. If I use any of those 5 methods > when the master is in focus, I get a segfault. Again, this is consistent > with the idea that the wxwidgets device is confusing windows events > from the two separate streams. I assume the fix is to change some variables > in the wxwidgets device code to be stored in a stream-dependent way similar > to changes we have made in other devices recently to deal with example 14. > > The "hit return" termination method and the 5 other termination > methods all work fine for the single-stream examples. > > Some comments on wxPLplotDemo. > > * The "hit return" method does nothing. Perhaps that should be changed to > be consistent with -dev wxwidgets > > * The 5 other termination methods terminate silently without the "Program > aborted" message (but also without a segfault). I am not sure whether you > want to be consistent with -dev wxwidgets here in generating the message. > Your call. > > * Could you change wxPLplotDemo to put the backend name in the title (like > you do for -dev wxwidgets)? > > * From the way the result looks, it appears it is using the default backend > rather than AGG. Could you change it to the same great defaults that occur > for -dev wxwidgets? > > * There are some funny discontinuities in the sinc curve displayed by > wxPLplotDemo compared to the nice smooth results in example 1. That may > simply be the result of using the default backend or it may be an additional > issue. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2009-01-23 10:09:18
|
Hi Alan, > > I confirm on my Debian testing platform that for revision 9358 > > ( TTFDIR=/usr/share/fonts/truetype ; > PLPLOT_FREETYPE_SANS_FONT=$TTFDIR/arphic/bkai00mp.ttf > PLPLOT_FREETYPE_SERIF_FONT=$TTFDIR/freefont/FreeSerif.ttf > PLPLOT_FREETYPE_MONO_FONT=$TTFDIR/ttf-devanagari-fonts/lohit_hi.ttf > PLPLOT_FREETYPE_SCRIPT_FONT=$TTFDIR/unfonts/UnBatang.ttf > PLPLOT_FREETYPE_SYMBOL_FONT=$TTFDIR/ttf-bengali-fonts/JamrulNormal.ttf > c/x24c -dev wxwidgets -drvopt smooth=0,freetype=1,text=0) > > gives pretty good (slightly ragged looking letters) results for the > AGG > backend. If I drop all the -drvopt stuff (which I believe is the > same as > smooth=1, freetype=1, and text=1), the results look outstanding. > It's great > that the default looks so good now (assuming the user has installed > libAGG). If you drop the -drvopt stuff, then the default is smooth=1,freetype=1,text=0. Text is the option to turn on/off the driver's own text processing, which doesn't work for the AGG backend anyway in the moment. > Here are the details for example 14. If I run the example the usual > two > windows are displayed (master and slave). If I hit return when the > slave is > in focus or the master in focus, both plot windows move on to the > next page. > If I hit return again in either master or slave, the process smoothly > terminates. Note, this behaviour is different then -dev xwin where a > hit of > return is ignored if it is done with the slave window in focus. That's > consistent with the idea that the slave should not affect the > master. The > wxwidgets issue of the slave being in control of the master could > just be a > minor side issue, but I think it is consistent with the idea that the > wxwidgets device is confusing windows events from the two separate > streams > which is a much more serious issue. As far as I remember that was made deliberately by me, since I never knew which is the slave and which is the master plot and was annoyed, that I always chose the wrong ;). So there is no mixing, but in the moment if you hit return in any window the main loop is "informed" to advance. I can have a look, how xwin does this logic and implement this as well for the wxwidgets driver. > > There are five other (besides hitting return) possible methods for > terminating the window. There are two window manager controls for > doing it > and the corresponding alt-F4 and the wxwidgets file button for exit > and the > corresponding alt-x. If I use any of those 5 methods when the slave > is in > focus, I get the "Program aborted" message. If I use any of those 5 > methods > when the master is in focus, I get a segfault. Again, this is > consistent > with the idea that the wxwidgets device is confusing windows events > from the two separate streams. I assume the fix is to change some > variables > in the wxwidgets device code to be stored in a stream-dependent way > similar > to changes we have made in other devices recently to deal with > example 14. I can confirm this and I'll have a look into this. Example 14 segfaulted for me now all the times, but removing the build tree and recompiling everything solved that. Seems that CMake got confused. Anyway gdb has also problems for the dynamic driver case, since it's segfaulting while the driver is loaded, that's also very annoying ;). Disabling the dynamic drivers allows me to debug it at least, at the first look this seems to be quite complicated, since it segfaults way after the close button is processed, in fact the program should never get there. I'll keep you informed. > > > The "hit return" termination method and the 5 other termination > methods all work fine for the single-stream examples. > > Some comments on wxPLplotDemo. > > * The "hit return" method does nothing. Perhaps that should be > changed to > be consistent with -dev wxwidgets Hmm, I don't think so, since it actually shouldn't be a demo similar to the other examples, it's just showing how to use the bindings and the demo should behave like a real application. But on the other side, it's then maybe easier to test in the test_interactice script, so I'll implement it. > > > * The 5 other termination methods terminate silently without the > "Program > aborted" message (but also without a segfault). I am not sure > whether you > want to be consistent with -dev wxwidgets here in generating the > message. > Your call. Yes, no message is better, you don't get such messages in "normal apps", I think this would confuse users. > > > * Could you change wxPLplotDemo to put the backend name in the title > (like > you do for -dev wxwidgets)? Will do. > > > * From the way the result looks, it appears it is using the default > backend > rather than AGG. Could you change it to the same great defaults > that occur > for -dev wxwidgets? Not in the moment, since the AGG backend doesn't work right now with the wxWidgets bindings. There is some fundamental problem making this work, but I'll definitely want to solve that. > > > * There are some funny discontinuities in the sinc curve displayed by > wxPLplotDemo compared to the nice smooth results in example 1. That > may > simply be the result of using the default backend or it may be an > additional > issue. Will look at that too. Thanks for the reports. Regards, Werner > > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-01-23 16:59:57
|
[Alan wrote]: >> when the master is in focus, I get a segfault. Again, this is consistent >> with the idea that the wxwidgets device is confusing windows events >> from the two separate streams. I assume the fix is to change some >> variables >> in the wxwidgets device code to be stored in a stream-dependent way similar >> to changes we have made in other devices recently to deal with example 14. > On 2009-01-23 11:08+0100 Werner Smekal wrote: > I can confirm this and I'll have a look into this. Example 14 segfaulted for > me now all the times, but removing the build tree and recompiling everything > solved that. Seems that CMake got confused. I noticed that (wxwidgets segfaults everywhere unless you remove the build tree and install tree [in my case since I am doing install-tree testing] and start fresh for any change) on Debian testing. Such a symptom happens for no other device that I am aware of. So I am quite surprised by this bad build result and will look into it further. Just to clarify for the others here the example 14 segfault happens for a fresh build and install, i.e., that's a "real" segfault as opposed to the widespread wxwidgets segfaults that occur if you don't have a fresh build tree and install tree. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2009-01-24 21:04:19
|
On 2009-01-23 08:59-0800 Alan W. Irwin wrote: > I noticed that (wxwidgets segfaults everywhere unless you remove the build > tree and install tree [in my case since I am doing install-tree testing] and > start fresh for any change) on Debian testing. Such a symptom happens for > no other device that I am aware of. So I am quite surprised by this bad > build result and will look into it further. This problem should now be fixed as of revision 9382. The fix involved a complete reorganization of FindAGG.cmake in standard CMake-2.6.x form. Please check this works on all platforms (especially Windows which has some special requirements for the case where pkg-config has not been installed). In a previous message I wrote: There are five other (besides hitting return) possible methods for terminating the window. There are two window manager controls for doing it and the corresponding alt-F4 and the wxwidgets file button for exit and the corresponding alt-x. If I use any of those 5 methods when the slave is in focus, I get the "Program aborted" message. If I use any of those 5 methods when the master is in focus, I get a segfault. Again, this is consistent with the idea that the wxwidgets device is confusing windows events from the two separate streams. I assume the fix is to change some variables in the wxwidgets device code to be stored in a stream-dependent way similar to changes we have made in other devices recently to deal with example 14. I can no longer reproduce this from a clean start (or otherwise). And valgrind also gives a clean bill of health when one of the above patterns of GUI use that previously caused segfaults is used. So the previous problems may well have been caused by some other linking problem that has now been fixed by the above standardization of FindAGG.cmake. I will accept this nice side effect of the change. :-) Werner, I believe you verified this segfault before for a clean start so I hope it is now gone for you as well. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2009-01-27 08:50:47
|
Hi Alan, > > There are five other (besides hitting return) possible methods for > terminating the window. There are two window manager controls for > doing > it and the corresponding alt-F4 and the wxwidgets file button for > exit and > the corresponding alt-x. If I use any of those 5 methods when the > slave > is in focus, I get the "Program aborted" message. If I use any of > those 5 > methods when the master is in focus, I get a segfault. Again, > this is > consistent with the idea that the wxwidgets device is confusing > windows > events from the two separate streams. I assume the fix is to > change some > variables in the wxwidgets device code to be stored in a stream- > dependent > way similar to changes we have made in other devices recently to > deal with > example 14. > > I can no longer reproduce this from a clean start (or otherwise). And > valgrind also gives a clean bill of health when one of the above > patterns of > GUI use that previously caused segfaults is used. So the previous > problems > may well have been caused by some other linking problem that has now > been > fixed by the above standardization of FindAGG.cmake. I will accept > this > nice side effect of the change. :-) > > Werner, I believe you verified this segfault before for a clean > start so I > hope it is now gone for you as well. Actually no, it still segfaults for me for wx 2.6 and 2.8 on Linux. A pity, since it's difficult to get hold of this bug, since it segfaults way after things have gone wrong. If I press the close button of the master window, the plot actually continues instead of aborting and then segfaults later on. Very strange. Thanks, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2009-01-19 13:45:07
|
On Mon, Jan 19, 2009 at 10:27:17PM +1000, Andrew Roach wrote: > > >I've pinned down the problem, but I'm not quite sure why the code is > >written the way it is. > > > >The problem arises in src/plfreetype.c in FT_PlotChar. There are two > >different code paths depending on whether the pixel mode is mono (i.e. > >no anti-aliasing) or not. However, the first path is also taken if icol0 > >= 0, i.e. the background colour. I can't quite see the logic for this. > >Normally is is not a problem since you wouldn't display text in the > >background colour. Example 24 however plots 4 coloured bands so you > >can't see the background, then switches to the background colour to > >print the text. The crazy fonts arise because the code assumes a mono > >font - i.e. each pixel is represented by one bit. This is not the case > >for the anti-aliased text in the background colour. I've just commented > >out this special case for icol0 = 0. I don't quite see why it was > >there in the first place. This fixes example 24. Perhaps someone better > >familiar with the freetype code could say why this was done originally? > > My recollection, late at night and a few years down the track, is that with > the "original anti-aliasing technique" (i.e. not the "BLENDED ANTIALIASING" > which 24bit supports, but the ugly anti-aliasing which also works with > 8bit), when the text colour had an index of "0", there were either > infrequent division by zero errors or some distracting psychedelic > anti-aliasing effects/artifacts. I can not remember which for sure, but > regardless dropping background coloured text back to non-antialiasing was > the quick way to fix the problem which had minimal impact since drawing > text with the background colour was virtually never done. In short, it was > a quick "design compromise" to fit the original simplistic code used for > anti-alaising when working with limited colours like 8 bit palettes used by > GIFs or the lower-resolution drivers of the day. Andrew, This makes sense, except that the quick-fix doesn't actually work because the freetype bitmap is not 1-bit. This could probably be fixed, but it may no longer be necessary in all cases anyway from what you say. Anti-aliasing doesn't work well with GIF's anyway for several of our examples, even before I made the change. A quick run of ctest on the png and gif drivers gives no division by zeros and the results for png at least look fine. Gif looks no worse. I am tempted to suggest turning off smoothing by default for 8-bit devices. We've already done this in the test suite for gif, but we could actually do it in the driver code. If you really want it you can still turn it on. An example where things go wrong with anti-aliasing on is example 2 (where a lot of colours are used anyway, so there are not enough left for anti-aliasing.) Andrew |