Menu
▾
▴
quesoglc-general — General purpose mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(9) |
Nov
|
Dec
(1) |
| 2007 |
Jan
|
Feb
(37) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(6) |
Sep
|
Oct
(9) |
Nov
(9) |
Dec
(2) |
| 2008 |
Jan
|
Feb
(9) |
Mar
(6) |
Apr
|
May
(2) |
Jun
(5) |
Jul
(4) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas Z. <td...@us...> - 2012-05-10 16:07:52
|
Hi, Sorry for the looong delay. As you can see, QuesoGLC is more or less un-maintained. You have to link against libGLC.so (not libglc.a). Since you're on Ubuntu, The file should be located in /usr/local/lib. You can link against it by adding -L/usr/local/lib -lGLC to your linker flags. Best regards Thomas Am Donnerstag, den 26.04.2012, 16:36 +0800 schrieb sakaibam: > Dear friends: > I am a new guy who is from China and want to use GLC on Ubuntu 11. > the GLC seems like very good, i guess i will love it. however i got > problems after i installed the GLC lib(quesoglc-0.7.2.tar.gz), i > couldn'f find the libglc.a, so it is failed to compile in CodeBlocks. > i searched in google, someone says i must add the libglc.a to the > linker, right? but where is the libglc.a? > Or can you please tell me how can i use GLC in my OS? what must i > follow? > > Please forget my bad english~~ > Thanks very much. > > > > > ______________________________________________________________________ > 网易Lofter，专注兴趣，分享创作！ > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ Quesoglc-general mailing list Que...@li... https://lists.sourceforge.net/lists/listinfo/quesoglc-general -- GnuPG: http://tdz.users.sourceforge.net/tdz.asc Fingerprint: 16FF F599 82F8 E5AA 18C6 5220 D9DA D7D4 4EF1 DF08 jsapigen - A free glue-code generator for Mozilla SpiderMonkey. See http://jsapigen.sourceforge.net for more information. |
|
From: sakaibam <sak...@16...> - 2012-04-26 08:36:49
|
Dear friends: I am a new guy who is from China and want to use GLC on Ubuntu 11. the GLC seems like very good, i guess i will love it. however i got problems after i installed the GLC lib(quesoglc-0.7.2.tar.gz), i couldn'f find the libglc.a, so it is failed to compile in CodeBlocks. i searched in google, someone says i must add the libglc.a to the linker, right? but where is the libglc.a? Or can you please tell me how can i use GLC in my OS? what must i follow? Please forget my bad english~~ Thanks very much. |
|
From: Paul W. <pa...@bo...> - 2011-09-17 21:14:59
|
On Sat, 2011-09-17 at 13:44 -0400, Matt Turner wrote: > With the new git repository, I expected to see some new patches or > something from the Warzone 2100 guys? That was the plan, unfortunately I haven't had time because I was travelling for two months. I'll be starting to work on this soon. -- bye, pabs http://bonedaddy.net/pabs3/ |
|
From: Matt T. <mat...@gm...> - 2011-09-17 17:45:15
|
On Thu, May 5, 2011 at 3:08 AM, Paul Wise <pa...@bo...> wrote: > On Sat, 2011-04-02 at 23:45 +0800, Paul Wise wrote: > >> For a start I wrote the attached script to convert the SVN repository to >> a git repository. It does a lot of filtering and stuff to match >> everything up with the git way of doing things. I'd appreciate it if you >> could run it and review the resulting git repository to make sure I >> didn't lose anything. I recommend running it on a tmpfs for speed. > > I've pushed the resulting git repository to sourceforge, can you disable > svn? IIRC that just hides it from the web page. > > -- > bye, > pabs With the new git repository, I expected to see some new patches or something from the Warzone 2100 guys? Matt |
|
From: Paul W. <pa...@bo...> - 2011-05-05 07:08:59
|
On Sat, 2011-04-02 at 23:45 +0800, Paul Wise wrote: > For a start I wrote the attached script to convert the SVN repository to > a git repository. It does a lot of filtering and stuff to match > everything up with the git way of doing things. I'd appreciate it if you > could run it and review the resulting git repository to make sure I > didn't lose anything. I recommend running it on a tmpfs for speed. I've pushed the resulting git repository to sourceforge, can you disable svn? IIRC that just hides it from the web page. -- bye, pabs http://bonedaddy.net/pabs3/ |
|
From: Paul W. <pa...@de...> - 2011-04-02 15:45:10
|
On Sat, 2011-04-02 at 13:03 +0200, Bertrand Coconnier wrote: > Sorry for the very long delay before answering. Indeed, I have not > worked on QuesoGLC for years now and will certainly not make any > progress in any foreseeable future. As you may have guessed my free time > does no longer allow me to dedicate time to the project. Thats a shame :( > So, in order to support the Warzone community, I would certainly be more > than happy to add a couple of new developers to QuesoGLC SourceForge > project. Excellent :) > For a start, I have added yourself 'pabs3' as a project member to > QuesoGLC. A git repository has been enabled and you have the rights to > commit to both SVN and git. You should normally be able to open/close > the bugs/feature/etc tickets as well. For a start I wrote the attached script to convert the SVN repository to a git repository. It does a lot of filtering and stuff to match everything up with the git way of doing things. I'd appreciate it if you could run it and review the resulting git repository to make sure I didn't lose anything. I recommend running it on a tmpfs for speed. > If you need any further help, just drop me an e-mail I will try to be > more responsive ;-) Will do. -- bye, pabs http://wiki.debian.org/PaulWise |
|
From: Bertrand C. <bco...@gm...> - 2011-04-02 11:03:16
|
Hi Paul, Le lundi 28 mars 2011 à 14:32 +0800, Paul Wise a écrit : > Hi Bertrand, > > The Warzone 2100 guys and myself noticed that you haven't been working > on QuesoGLC recently. If you don't intend to work on it any time soon, > would you consider giving myself and one of the Warzone 2100 guys admin > access so that we can update the code, close bugs and maybe migrate from > SVN to git? > Sorry for the very long delay before answering. Indeed, I have not worked on QuesoGLC for years now and will certainly not make any progress in any foreseeable future. As you may have guessed my free time does no longer allow me to dedicate time to the project. So, in order to support the Warzone community, I would certainly be more than happy to add a couple of new developers to QuesoGLC SourceForge project. For a start, I have added yourself 'pabs3' as a project member to QuesoGLC. A git repository has been enabled and you have the rights to commit to both SVN and git. You should normally be able to open/close the bugs/feature/etc tickets as well. If you need any further help, just drop me an e-mail I will try to be more responsive ;-) Bertrand. |
|
From: Paul W. <pa...@de...> - 2011-03-28 06:32:38
|
Hi Bertrand, The Warzone 2100 guys and myself noticed that you haven't been working on QuesoGLC recently. If you don't intend to work on it any time soon, would you consider giving myself and one of the Warzone 2100 guys admin access so that we can update the code, close bugs and maybe migrate from SVN to git? -- bye, pabs http://wiki.debian.org/PaulWise |
|
From: Paul W. <pa...@bo...> - 2010-11-24 04:00:01
|
Hey, Some warzone2100 folks and I noticed that your work on QuesoGLC has been slowing down recently. Would you accept new folks in the project? Some goals for myself and warzone2100 folks we would like to fix: Drop the embedded code copies. This caused an issue for wz folks because they switched from GLee to GLEW and thus had multiple copies of the lib being linked statically into the same binary and conflicting. Debian has a policy of removing embedded code copies for various reasons. There are some issues on 64-bit MacOS X that wz folks ran into: http://sourceforge.net/support/tracker.php?aid=3087141 Some chinese font issues: http://sourceforge.net/support/tracker.php?aid=3091650 You are also using SVN rather than a more modern VCS like git. -- bye, pabs http://bonedaddy.net/pabs3/ |
|
From: Paul W. <pa...@bo...> - 2010-06-23 02:28:59
|
Hi, I'm wondering if you are able to help out with this bug: http://bugs.debian.org/585757 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585669#28 -- bye, pabs http://bonedaddy.net/pabs3/ |
|
From: Paul W. <pa...@bo...> - 2010-06-20 14:44:02
|
On Sun, 2010-06-20 at 16:20 +0200, Bertrand Coconnier wrote: > You can do whichever way you want: Thanks for the info. I went with letting the destructor remove them. -- bye, pabs http://bonedaddy.net/pabs3/ |
|
From: Bertrand C. <bco...@gm...> - 2010-06-20 14:20:56
|
2010/6/20 Paul Wise <pa...@bo...>: > On Sat, 2010-06-19 at 19:54 +0200, Bertrand Coconnier wrote: > >> Your fix therefore makes sense but the call to glcGetError occurs a >> bit too late IMHO. I suggest to handle the error as soon as it occurs >> as the small patch attached suggests. > > Excellent, thanks for that. > > I'm wondering if the ids from glcGenFontID need to be deallocated > somehow and the variables set to 0 when the call to glcNewFontFromFamily > fails, any thoughts? Or should I leave it to the deconstructor to call > glcDeleteFont on them and set them to 0 then? > You can do whichever way you want: GLC knows that IDs created with glcGenFontID are allocated by the user and never will use them itself unless it is explicitly told so by the user. If some fonts are created automatically by GLC, it will create additional font IDs accordingly. There is no risk of collision (or it is a bug in QuesoGLC). However if you want to be conservative and release these font IDs, you can call glcDeleteFont on them. GLC will then release the corresponding allocated memory and know that these IDs are no longer reserved by the user. You have also to remember that these reserved IDs are destroyed when glcDeletedContext is called. That means that, even if the IDs are not explicitly released, their number will not grow indefinitely in your program. We are talking of a few hundred of bytes here. So I don't think it matters much from that a memory consumption point of view. Your decision will really depends on code cleanliness rather than anything else. Regards, Bertrand. |
|
From: Paul W. <pa...@bo...> - 2010-06-20 05:21:11
|
On Sat, 2010-06-19 at 19:54 +0200, Bertrand Coconnier wrote: > Your fix therefore makes sense but the call to glcGetError occurs a > bit too late IMHO. I suggest to handle the error as soon as it occurs > as the small patch attached suggests. Excellent, thanks for that. I'm wondering if the ids from glcGenFontID need to be deallocated somehow and the variables set to 0 when the call to glcNewFontFromFamily fails, any thoughts? Or should I leave it to the deconstructor to call glcDeleteFont on them and set them to 0 then? -- bye, pabs http://bonedaddy.net/pabs3/ |
|
From: Bertrand C. <bco...@gm...> - 2010-06-19 17:55:00
|
Hi Paul, I think I have found what is going wrong : the constructor of TextGLC is called assuming that no error occurred in GLC before. This assumption is true when the constructor is called for the 1st time. Unfortunately when GLC cannot find the font "Gothic Uralic" it aborts glcNewFontFromFamily and sets the GLC error flag to GLC_RESOURCE_ERROR (i.e. to 65). The error flag is never reset to GLC_NONE afterwards, therefore when the constructor of TextGLC is called a second time, it throws an exception. The issue here is that the exception is not linked to an error in the creation of a new context but is due to an error which has occurred much before. Your fix therefore makes sense but the call to glcGetError occurs a bit too late IMHO. I suggest to handle the error as soon as it occurs as the small patch attached suggests. Unless I am mistaken, this issue is therefore not triggered by QuesoGLC. I hope this helps. Regards, Bertrand. 2010/6/19 Bertrand Coconnier <bco...@gm...>: > Hi Paul, > > I can reproduce the bug here on Ubuntu 10.04. > I will investigate and tell you my findings. > > Regards, > > Bertrand. > > 2010/6/19 Paul Wise <pa...@bo...>: >> On Mon, 2010-06-07 at 11:17 +0800, Paul Wise wrote: >> >>> Not sure if you remember, but you helped me add support for GLC to >>> Chromium B.S.U. a while ago: >>> >>> http://chromium-bsu.git.sourceforge.net/git/gitweb.cgi?p=chromium-bsu/chromium-bsu;a=blob;f=src/TextGLC.cpp >>> >>> I've been noticing a particular problem found by users non-Debian >>> distributions. When any one of the fonts requested doesn't exist on the >>> system, the second time the GLC context is created, glcGetError returns >>> GLC_RESOURCE_ERROR instead of success. For the first initialisation >>> everything works fine and fonts are rendered etc. AFAICT I'm destroying >>> all the GlC resources in the appropriate way before recreating them. The >>> re-initialisation of GLC occurs when the screen size is changed by the >>> user, since the font size needs to change. I didn't notice this on >>> Debian because I always have the default font installed. I'm wondering >>> if you had any insights into this bug? >> >> I was able to work around this issue by calling glcGetError() after >> destroying the GLC context. I'm thinking this is a problem with QuesoGLC >> but I am not sure where the issue is. >> >> In case you are interested, here is a log I created. The TLS lines are >> printed when GLC_GET_THREAD_AREA() is called and the number is the value >> of errorState. The lines containing QuesoGLC file names and line numbers >> are where the __glcRaiseError function is called. >> >> $ chromium-bsu >> TLS 0 >> TLS 0 >> TLS 0 >> TLS 0 >> TLS 0 >> TLS 0 >> TLS 0 >> TLS 0 >> TLS 0 >> ../src/global.c:572 >> TLS 0 >> ../src/global.c:708 >> ../src/omaster.c:467 >> ../src/font.c:94 >> ../src/font.c:94 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> TLS 65 >> ../src/global.c:572 >> TLS 65 >> ../src/global.c:708 >> error loading font: GLC: couldn't set context >> TLS 0 >> TLS 0 >> >> -- >> bye, >> pabs >> >> http://bonedaddy.net/pabs3/ >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Quesoglc-general mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesoglc-general >> >> > |
|
From: Bertrand C. <bco...@gm...> - 2010-06-19 17:07:37
|
Hi Paul, I can reproduce the bug here on Ubuntu 10.04. I will investigate and tell you my findings. Regards, Bertrand. 2010/6/19 Paul Wise <pa...@bo...>: > On Mon, 2010-06-07 at 11:17 +0800, Paul Wise wrote: > >> Not sure if you remember, but you helped me add support for GLC to >> Chromium B.S.U. a while ago: >> >> http://chromium-bsu.git.sourceforge.net/git/gitweb.cgi?p=chromium-bsu/chromium-bsu;a=blob;f=src/TextGLC.cpp >> >> I've been noticing a particular problem found by users non-Debian >> distributions. When any one of the fonts requested doesn't exist on the >> system, the second time the GLC context is created, glcGetError returns >> GLC_RESOURCE_ERROR instead of success. For the first initialisation >> everything works fine and fonts are rendered etc. AFAICT I'm destroying >> all the GlC resources in the appropriate way before recreating them. The >> re-initialisation of GLC occurs when the screen size is changed by the >> user, since the font size needs to change. I didn't notice this on >> Debian because I always have the default font installed. I'm wondering >> if you had any insights into this bug? > > I was able to work around this issue by calling glcGetError() after > destroying the GLC context. I'm thinking this is a problem with QuesoGLC > but I am not sure where the issue is. > > In case you are interested, here is a log I created. The TLS lines are > printed when GLC_GET_THREAD_AREA() is called and the number is the value > of errorState. The lines containing QuesoGLC file names and line numbers > are where the __glcRaiseError function is called. > > $ chromium-bsu > TLS 0 > TLS 0 > TLS 0 > TLS 0 > TLS 0 > TLS 0 > TLS 0 > TLS 0 > TLS 0 > ../src/global.c:572 > TLS 0 > ../src/global.c:708 > ../src/omaster.c:467 > ../src/font.c:94 > ../src/font.c:94 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > TLS 65 > ../src/global.c:572 > TLS 65 > ../src/global.c:708 > error loading font: GLC: couldn't set context > TLS 0 > TLS 0 > > -- > bye, > pabs > > http://bonedaddy.net/pabs3/ > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Quesoglc-general mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesoglc-general > > |
|
From: Paul W. <pa...@bo...> - 2010-06-19 10:18:45
|
On Mon, 2010-06-07 at 11:17 +0800, Paul Wise wrote: > Not sure if you remember, but you helped me add support for GLC to > Chromium B.S.U. a while ago: > > http://chromium-bsu.git.sourceforge.net/git/gitweb.cgi?p=chromium-bsu/chromium-bsu;a=blob;f=src/TextGLC.cpp > > I've been noticing a particular problem found by users non-Debian > distributions. When any one of the fonts requested doesn't exist on the > system, the second time the GLC context is created, glcGetError returns > GLC_RESOURCE_ERROR instead of success. For the first initialisation > everything works fine and fonts are rendered etc. AFAICT I'm destroying > all the GlC resources in the appropriate way before recreating them. The > re-initialisation of GLC occurs when the screen size is changed by the > user, since the font size needs to change. I didn't notice this on > Debian because I always have the default font installed. I'm wondering > if you had any insights into this bug? I was able to work around this issue by calling glcGetError() after destroying the GLC context. I'm thinking this is a problem with QuesoGLC but I am not sure where the issue is. In case you are interested, here is a log I created. The TLS lines are printed when GLC_GET_THREAD_AREA() is called and the number is the value of errorState. The lines containing QuesoGLC file names and line numbers are where the __glcRaiseError function is called. $ chromium-bsu TLS 0 TLS 0 TLS 0 TLS 0 TLS 0 TLS 0 TLS 0 TLS 0 TLS 0 ../src/global.c:572 TLS 0 ../src/global.c:708 ../src/omaster.c:467 ../src/font.c:94 ../src/font.c:94 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 TLS 65 ../src/global.c:572 TLS 65 ../src/global.c:708 error loading font: GLC: couldn't set context TLS 0 TLS 0 -- bye, pabs http://bonedaddy.net/pabs3/ |
|
From: Bertrand C. <bco...@gm...> - 2009-03-31 20:55:08
|
After 2 release candidates and 1 year after release 0.7.1, version 0.7.2 is finally released. Release 0.7.2 is a bug fix release. Many bugs have been fixed with respect to 0.7.1. More details in the change log. Upgrade is recommended. Enjoy! Bertrand. |
|
From: Bertrand C. <bco...@gm...> - 2009-02-22 18:49:16
|
QuesoGLC 0.7.2 is intended to be a bug fix release. Many bugs have been fixed with respect to release 0.7.1. For this second release candidate there are some additional bugs which have been fixed with respect to the Release Candidate 1. More details in the Change Log as usual. It is unusual for QuesoGLC to issue release candidates but I have no access to a Windows or Mac OS X platform at the moment. Hence QuesoGLC 0.7.2 has only been tested under Linux. It should be very stable however, and everybody is encouraged to download this new 0.7.2 RC2 release and to test it. As always, bugs report are very welcome. Positive feedback is also welcome, especially from users which use Windows or Mac OS X. Regards, Bertrand. |
|
From: Bertrand C. <bco...@gm...> - 2008-10-25 10:09:18
|
QuesoGLC 0.7.2 is intended to be a bug fix release. Many bugs have been fixed with respect to release 0.7.1. Moreover, you should notice a slight visual improvement for textured fonts rendered at small sizes. This improvement is the consequence of a bug fix. More details in the Change Log as usual. It is unusual for QuesoGLC to issue release candidates but I have no access to a Windows or Mac OS X platform at the moment. Hence QuesoGLC 0.7.2 has only been tested under Linux. It should be very stable however, and everybody is encouraged to download this new 0.7.2 RC1 release and to test it. As always, bugs report are very welcome. Positive feedback is also welcome, especially from users which use Windows or Mac OS X. Regards, Bertrand. |
|
From: Bertrand C. <bco...@gm...> - 2008-08-17 10:26:38
|
All, I plan to release 0.7.2 by the end of August whether the outstanding bugs are fixed or not. It has become very difficult to obtain feedback from bug posters those last weeks and I am sure they will understand that I can not delay the release forever. The remaining bugs will be fixed in release 0.8.0 or 0.7.3 depending on whichever is the more pertinent at that time. Regards, Bertrand. 2008/7/23 Per Inge Mathisen <per...@gm...>: > On Wed, Jul 23, 2008 at 12:54 AM, Giel van Schijndel <me...@mo...> wrote: >>> * bug #2019450 : Capital 'V' is not displayed on Fedora 9 >> >> NOTE: I know Per has had exactly this problem. I'm not sure if he still >> has it. >> >> @ Per: do you? > > Yes. I will try to get time to look more closely into this soon. > > It is rather strange, though. All other letters are visible, only the > capital 'V' is missing... > > - Per |
|
From: Bertrand C. <bco...@gm...> - 2008-08-09 10:10:43
|
I went to the OpenGL forums to see if there is something similar reported and I found some entries which may be of interest to you. Basically, they say the NVidia drivers under Win32 have some problems with multicore processors, so they suggest to force the application to use only one core at a time. Better explanations in the links below : http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=241429#Post241429 http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=164629#Post164629 Please try and tell me if it fixes your issue. Regards, Bertrand. 2008/8/9 GenPFault <gen...@gm...>: > Weird, on my home machine (Core 2 Duo, NVidia 8800GTS, the old 640MB > version), I'm getting ~200ms in Windows (32-bit). I'll give my Debian > install a shot and see if anything changes... > > ...and on my amd64 Debian install (same machine) I get ~30ms. Huh. > That's...odd. > > Getting rid of the glFinish() in Win32 didn't change the speed at all, > and neither did switching to Release mode. Don't know what to tell > you :( > > -Charles > > On Fri, Aug 1, 2008 at 3:54 PM, Bertrand Coconnier <bco...@gm...> wrote: >> Hi GenPFault, >> >> I tested your example on a Linux Laptop (Intel Dual Core @ 1.6 GHz + >> Intel GMA X3100) and got 35 ms for "exp_avg". Note that Intel GMA >> X3100 is not the faster gfx card ever... and I obtain speed 10 times >> faster than yours ?!? Actually Intel X3100 is a (very) slow gfx card >> compared to my good old NVidia GeForce 6800. However, I have no access >> to a Windows box at the moment nor to my desktop PC so I can not >> investigate further for now. >> >> On your side, did you deactivate the monitor sync before running the >> test ? Sync @ 60 Hz is sometimes enabled by default by gfx drivers. >> >> Regards, >> >> Bertrand. >> >> 2008/6/9 GenPFault <gen...@gm...>: >>> Attached is a simple benchmark. Rendering what amounts to a screen >>> full of text ("abcdefghij" rotated and drawn 200 times = 2000 >>> characters; VGA text mode is 80 columns * 25 rows = 2000 characters) >>> takes a bit over 300ms on the Radeon X1300 I have. It appears that >>> using display lists in conjunction with GLC_TEXTURE is unsupported or >>> at least strongly discouraged; is there an alternative for drawing >>> large amounts of text? >>> >>> Thanks! >>> -genpfault >> > |
|
From: Bertrand C. <bco...@gm...> - 2008-08-07 20:56:26
|
Hi Tim, I uploaded GenPfault's binary archive in the File Release System (category QuesoGLC binary deps for Win32). Regards, Bertrand. 2008/8/7 Tim Baumgartner <ti...@gm...>: > Bertrand, > > Could you send me or tell me where I can download the QuesoGLC DLL from the > post below? When using the Win32 libs that are posted on Sourceforge I > always get what looks like a seg fault (or whatever they're called on > Windows) when QuesoGLC calls the fontconfig DLL (from > http://www.gimp.org/~tml/gimp/win32/downloads.html). This new DLL might be > worth a try. > > Thanks, > Tim > > Bertrand Coconnier wrote: >> >> Hi Charles, >> >> Thanks for the binary I think it will be useful. Not sure that I >> should include it in SVN however. Two reasons not to do that : >> 1. This would add the burden of checking on a regular basis that those >> DLLs are the most recent versions (i.e. versions which include the >> very last security patches and so on) >> 2. It would add several Mb of useless downloading for users of >> platforms others than Windows. >> At the moment I think it would be much better to put it in the file >> release system of SourceForge and tell Windows users that they can get >> the DLLs by downloading this file on SourceForge. >> >> Speaking about src/database.c, it has never been included in SVN and >> never will. Actually this file is built from the Unicode database so >> rather than updating it manually when the Unicode DB evolves, I wrote >> a little Python script database/buildDB.py which downloads the latest >> release of the Unicode DB and builds the file src/database.c >> accordingly. This script is automatically executed if you use the >> Makefiles. However, it is not called in the VC++ project build. In >> this case, you can either execute it yourself if Python is installed >> on your Windows box or copy src/database.c from a previous QuesoGLC >> release since its format is stable over the releases. >> >> You may have understood that I am not a great specialist of VC++ so if >> there is a better way to handle the Python script please let me know. >> >> Concerning the tests for the bugs, I would suggest to use the branch >> release-0.7 >> (https://quesoglc.svn.sourceforge.net/svnroot/quesoglc/branches/release-0.7/quesoglc) >> rather than the trunk since the former is much more stable. >> >> Regards, >> >> Bertrand. >> >> 2008/8/7 GenPFault <gen...@gm...>: >>> >>> Heyo! >>> >>> No worries, I've been pretty busy myself. >>> >>> Hallelujah! Got it to build w/o mingw/msys in Visual Studio Express. >>> Everyone loves win32 dependency whack-a-mole :) I've attached the >>> binaries I found that worked. Just copy it over a HEAD checkout and >>> the Studio project should 'just work'. >>> >>> It seems src/database.c disappeared sometime between the 0.7.1 tarball >>> and HEAD. The HEAD Studio project still references it and HEAD >>> refuses to build completely without it. >>> >>> I should be able to take a look at the bug tomorrow. >>> >>> Thanks! >>> -Charles >>> >>> >>> >>> On Fri, Aug 1, 2008 at 1:02 PM, Bertrand Coconnier <bco...@gm...> >>> wrote: >>>> >>>> Hi GenPFault, >>>> >>>> First of all, sorry about such a huge delay before answering. I have >>>> been away from the internet for quite a while (I moved abroad and >>>> things are always much more complicated when you discover a new >>>> country). >>>> >>>> Anyway, I obtained the same result as the one you reported under >>>> Linux. After some investigations, I am pretty sure that the issue you >>>> reported is a consequence of the bug #1935557 (Wrong behaviour of >>>> glcResolution with GLC_TEXTURE). In order to be sure that this is the >>>> case, I suggest that you run your example with line 100 replaced by >>>> "glcResolution(72);". If the bug does not exhibit when resolution is >>>> set to 72 dpi then your problem has been fixed in SVN (either trunk or >>>> branch "release-0.7"). >>>> >>>> Regards, >>>> >>>> Bertrand. >>>> >>>> 2008/6/9 GenPFault <gen...@gm...>: >>>>> >>>>> Attached are an example program and its output showing a rendering >>>>> problem with the W glyph, at least in Arial and Times New Roman; >>>>> Courier New and Lucida Console (perhaps all mono space fonts?) seem >>>>> unaffected. >>>>> >>>>> glcDisable(GLC_GL_OBJECTS) appears to prevent the problem, although >>>>> doing so makes lower-case 'L's disappear at scale < 22. >>>>> >>>>> 0.7.1 win32 binaries, Windows XP SP2, Visual Studio 2005. >>>>> >>>>> -genpfault >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Quesoglc-general mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesoglc-general >> > > |
|
From: Bertrand C. <bco...@gm...> - 2008-08-07 19:04:50
|
Hi Charles, Thanks for the binary I think it will be useful. Not sure that I should include it in SVN however. Two reasons not to do that : 1. This would add the burden of checking on a regular basis that those DLLs are the most recent versions (i.e. versions which include the very last security patches and so on) 2. It would add several Mb of useless downloading for users of platforms others than Windows. At the moment I think it would be much better to put it in the file release system of SourceForge and tell Windows users that they can get the DLLs by downloading this file on SourceForge. Speaking about src/database.c, it has never been included in SVN and never will. Actually this file is built from the Unicode database so rather than updating it manually when the Unicode DB evolves, I wrote a little Python script database/buildDB.py which downloads the latest release of the Unicode DB and builds the file src/database.c accordingly. This script is automatically executed if you use the Makefiles. However, it is not called in the VC++ project build. In this case, you can either execute it yourself if Python is installed on your Windows box or copy src/database.c from a previous QuesoGLC release since its format is stable over the releases. You may have understood that I am not a great specialist of VC++ so if there is a better way to handle the Python script please let me know. Concerning the tests for the bugs, I would suggest to use the branch release-0.7 (https://quesoglc.svn.sourceforge.net/svnroot/quesoglc/branches/release-0.7/quesoglc) rather than the trunk since the former is much more stable. Regards, Bertrand. 2008/8/7 GenPFault <gen...@gm...>: > Heyo! > > No worries, I've been pretty busy myself. > > Hallelujah! Got it to build w/o mingw/msys in Visual Studio Express. > Everyone loves win32 dependency whack-a-mole :) I've attached the > binaries I found that worked. Just copy it over a HEAD checkout and > the Studio project should 'just work'. > > It seems src/database.c disappeared sometime between the 0.7.1 tarball > and HEAD. The HEAD Studio project still references it and HEAD > refuses to build completely without it. > > I should be able to take a look at the bug tomorrow. > > Thanks! > -Charles > > > > On Fri, Aug 1, 2008 at 1:02 PM, Bertrand Coconnier <bco...@gm...> wrote: >> Hi GenPFault, >> >> First of all, sorry about such a huge delay before answering. I have >> been away from the internet for quite a while (I moved abroad and >> things are always much more complicated when you discover a new >> country). >> >> Anyway, I obtained the same result as the one you reported under >> Linux. After some investigations, I am pretty sure that the issue you >> reported is a consequence of the bug #1935557 (Wrong behaviour of >> glcResolution with GLC_TEXTURE). In order to be sure that this is the >> case, I suggest that you run your example with line 100 replaced by >> "glcResolution(72);". If the bug does not exhibit when resolution is >> set to 72 dpi then your problem has been fixed in SVN (either trunk or >> branch "release-0.7"). >> >> Regards, >> >> Bertrand. >> >> 2008/6/9 GenPFault <gen...@gm...>: >>> Attached are an example program and its output showing a rendering >>> problem with the W glyph, at least in Arial and Times New Roman; >>> Courier New and Lucida Console (perhaps all mono space fonts?) seem >>> unaffected. >>> >>> glcDisable(GLC_GL_OBJECTS) appears to prevent the problem, although >>> doing so makes lower-case 'L's disappear at scale < 22. >>> >>> 0.7.1 win32 binaries, Windows XP SP2, Visual Studio 2005. >>> >>> -genpfault >> > |
|
From: Bertrand C. <bco...@gm...> - 2008-08-01 20:54:52
|
Hi GenPFault,
I tested your example on a Linux Laptop (Intel Dual Core @ 1.6 GHz +
Intel GMA X3100) and got 35 ms for "exp_avg". Note that Intel GMA
X3100 is not the faster gfx card ever... and I obtain speed 10 times
faster than yours ?!? Actually Intel X3100 is a (very) slow gfx card
compared to my good old NVidia GeForce 6800. However, I have no access
to a Windows box at the moment nor to my desktop PC so I can not
investigate further for now.
On your side, did you deactivate the monitor sync before running the
test ? Sync @ 60 Hz is sometimes enabled by default by gfx drivers.
Regards,
Bertrand.
2008/6/9 GenPFault <gen...@gm...>:
> Attached is a simple benchmark. Rendering what amounts to a screen
> full of text ("abcdefghij" rotated and drawn 200 times = 2000
> characters; VGA text mode is 80 columns * 25 rows = 2000 characters)
> takes a bit over 300ms on the Radeon X1300 I have. It appears that
> using display lists in conjunction with GLC_TEXTURE is unsupported or
> at least strongly discouraged; is there an alternative for drawing
> large amounts of text?
>
> Thanks!
> -genpfault
|
|
From: Bertrand C. <bco...@gm...> - 2008-08-01 18:02:22
|
Hi GenPFault, First of all, sorry about such a huge delay before answering. I have been away from the internet for quite a while (I moved abroad and things are always much more complicated when you discover a new country). Anyway, I obtained the same result as the one you reported under Linux. After some investigations, I am pretty sure that the issue you reported is a consequence of the bug #1935557 (Wrong behaviour of glcResolution with GLC_TEXTURE). In order to be sure that this is the case, I suggest that you run your example with line 100 replaced by "glcResolution(72);". If the bug does not exhibit when resolution is set to 72 dpi then your problem has been fixed in SVN (either trunk or branch "release-0.7"). Regards, Bertrand. 2008/6/9 GenPFault <gen...@gm...>: > Attached are an example program and its output showing a rendering > problem with the W glyph, at least in Arial and Times New Roman; > Courier New and Lucida Console (perhaps all mono space fonts?) seem > unaffected. > > glcDisable(GLC_GL_OBJECTS) appears to prevent the problem, although > doing so makes lower-case 'L's disappear at scale < 22. > > 0.7.1 win32 binaries, Windows XP SP2, Visual Studio 2005. > > -genpfault |
2 messages has been excluded from this view by a project administrator.
