STR #1656: fl_circle is filled on unix, open on windows

STR #1656

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	4 - High, e.g. key functionality not working
Scope:	2 - Specific to an operating system
Subsystem:	WIN32
Summary:	fl_circle is filled on unix, open on windows
Version:	1.1-current
Created By:	a.rburgers.quicknet
Assigned To:	matt
Fix Version:	1.1-current (SVN: v5823)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	a.rburgers.quicknet 06:12 Apr 17, 2007

circle.cxx
1k

#2	a.rburgers.quicknet 06:13 Apr 17, 2007

run_circle.sh
0k

#3	a.rburgers.quicknet 01:19 Apr 23, 2007

OSF.png
4k

#4	a.rburgers.quicknet 01:20 Apr 23, 2007

windows.png
5k

#5	a.rburgers.quicknet 01:20 Apr 23, 2007

circle_v2.cxx
1k

#6	a.rburgers.quicknet 12:55 May 02, 2007

symbols.png
9k

#7	matt 13:55 May 02, 2007

symbols.exe
180k

#8	a.rburgers.quicknet 14:38 May 02, 2007

dlls_symbols_matt.txt
1k

#9	a.rburgers.quicknet 14:38 May 02, 2007

dll_cygwin_hosted_mingw_symbols.txt
0k

#10	ianmacarthur 04:50 May 09, 2007

mine.png
9k

#11	ianmacarthur 04:50 May 09, 2007

matt.png
9k

#12	ianmacarthur 04:50 May 09, 2007

pixel_diffs.png
3k

#13	ianmacarthur 12:33 May 11, 2007

clock_err.png
10k

Trouble Report Comments:

#1	a.rburgers.quicknet 06:12 Apr 17, 2007

fl_circle will draw a filled circle on unix (I tried OSF). fl_circle draws an open circle on windows. It used to draw filled circles on windows as well. The attached files circle.cxx and run_circle.sh can be used to reproduce the problem.

#2	a.rburgers.quicknet 01:22 Apr 23, 2007

- updated the file circle.cxx with a comparison with fl_arc. - added an X-11 and a windows screenshot. fl_arc(x, y, r, 0, 360) is filled on windows, fl_circle(x, y, r) is not.

#3	matt 07:16 May 01, 2007

The MSWindows version is wrong. Since you are doing this inside fl_polygon, the circle should be filled.

#4	matt 05:15 May 02, 2007

Hmm, nothing wrong here on XP SP2. Please try to recompile FLTK completely. Also, if you look at the symbols demo, are the circles filled there? Looking at the code, there is nothing that should keep the circle from being drawn filled.

#5	a.rburgers.quicknet 13:02 May 02, 2007

Have tested it on a computer with XP SP2 (home edition NL), both the cygwin and mingw versions (r5798). Have looked at both shared and statically linked versions. Also on an msys built version on W2000 professional NL.(r5798) Initial report was on a computer with XP SP2 (professional edition NL). So far I have only seen open circles in the symbols demo...

#6	matt 13:52 May 02, 2007

Thanks for verifying this for me. I will see that I get a Cygwind build going and try to repeat this. Otherwise, I would not know how to fix it. Oh, a few more questions: - which graphics card are you using and do you have the newest driver? - what is your screen resolution and depth?

#7	matt 13:54 May 02, 2007

Also, I will attach an executable here that is verified on my machine to work correctly. If it fails on your machine, we are likely having some driver issue. If it doesn't fail, we'll have to track the build process.

#8	a.rburgers.quicknet 14:31 May 02, 2007

Your symbols.exe does indeed display a filled circle. How was that one created?

#9	a.rburgers.quicknet 14:40 May 02, 2007

ran cygwin's cygcheck on my mingw symbols.exe and yours. Yours has a reference to comctl32.dll, which mine doesn't. Have no idea whether that is significant.

#10	ianmacarthur 00:36 May 08, 2007

Gents, Just tried running Matt's symbols.exe and mine (built with mingw/Msys on WinXP with an Intel graphics card/driver.) Using fltk-1.1 from svn as of this morning. So - "my" circle symbol is un-filled, Matt's circle is filled. Also, I notice that several of the symbols drawn are *not* pixel identical, which was a surprise. In particular the "filesave" images appear different, and the bars produced by @>[] and @>| (and their reverses) are visibly "thinner" in my version than in Matt's version. -- Ian

#11	ianmacarthur 04:49 May 09, 2007

OK, just for the record, here's a series of PNG's that show the pixel differences produced by diff'ing the symbols.exe that my mingw build produces against the (VC based??) version that Matt posted... Odd.

#12	matt 12:49 May 09, 2007

Allrighty, I just compiled the current SVN FLTK1 from scratch using the current incarnation of Cygwin (fixed a configuration problem in FLTK while I was at it), and guess what: my circles are all filled nicely. So, um, what can we do next to fix this? My gcc is V3.4.4

#13	a.rburgers.quicknet 14:03 May 10, 2007

I just tried this: ./configure '--enable-localjpeg=yes' '--enable-localzlib=yes' '--enable-localpng=yes' This uses cygwin as host platform to create a mingw executable. Still open circles here. Used r5808. Stock gcc 3.4.4 here as well. I am amazed that you get the closed ones. What was your exact configure incantation?

#14	AlbrechtS 07:16 May 11, 2007

Just to add my test results with cygwin/mingw. I used similar config. options as a.rburgers, and I do also get the open circle in test/symbols.exe. My cygcheck output (DLLs) looks exactly the same as in the file dll_cygwin_hosted_mingw_symbols.txt. FLTK svn 1.1-r5808 (current version) gcc --version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) I tried the same with linux, and there I see a closed circle (on an X display on my windows box). HTH Albrecht

#15	ianmacarthur 12:31 May 11, 2007

Well, as another data point, I have mingw "stable" which is gcc 3.4.2, on XP. It draws "empty" circles when built from latest svn. Mingw have a gcc 3.4.5 in work but it's not in their stable tree yet. Some thoughts: - The "easy fix" is to replace the call to fl_circle(0,0,1); with one for fl_arc(0,0,1,0,360); in draw_circle() in fl_symbols.cxx. This "works" in that the circle *is* drawn filled in now - but the infill is larger than the darker bounding circle in some zoom cases - must be different rounding in the different rendering cases... - fl_circle seems to maybe not work at all. Some basic tests I have done on this machine seem to always draw un-filled circles. (The same code on linux draws filled circles.) It really looks as if the call to "Pie" at line 307 in fl_vertex just does the same as the call to "Arc" does... - Perhaps there is a more general malaise with fl_circle on win32? I now find that the FL_Round_Clock does not redraw properly (image attached) where the "plain" clock does - again, it looks as if fl_circle is not drawing a filled circle on this machine. - Does the fact that this works OK for Matthias suggest there is some issue with the win32 headers? Maybe he has different headers... Matt, do you have VC installed? Is it possible the VC installation "fixes" something that is otherwise awry in the cygwin/mingw environment? - or something...

#16	ianmacarthur 13:19 May 11, 2007

Another thought was whether using: Ellipse(fl_gc, llx, lly, llx+w, lly+h); might be better than the existing: Pie(fl_gc, llx, lly, llx+w, lly+h, 0,0, 0,0); But in my test so far it makes no difference...

#17	matt 13:51 May 11, 2007

I do have VC6, VC7, and VC2005 installed, but I doubt that this makes a difference. I compile using "configure --enable-threads --enable-debug", all from scratch (make distclean; autoconf; ./configure ...). You implied that the behavior changed from earlier versions of FLTK. Would it be possible to find out, which 'commit' introduced the bug?

#18	ianmacarthur 14:38 May 11, 2007

OK, here's an observation - seems to be some sort of compiler bug... I discovered that the code was taking a path through fl_circle() as if the line-type variable "what" was *not* set == POLYGON. So I added a printf() just before it... and now the code works correctly... I'm thinking the optimiser is maybe optimising out the test or something, around line 305 of fl_vertex.cxx... Mind you a few feeble attempts to "fix" it, short of the printf(), have so far failed!

#19	a.rburgers.quicknet 14:51 May 11, 2007

And here is another observation, that offers a bit of a clue I get filled circles as well, when I configure as follows: ./configure '--enable-localjpeg=yes' '--enable-localzlib=yes' '--enable-localpng=yes' '--enable-debug' This is consistent with Ian's observation that it might be a compiler problem with the default -Os.

#20	ianmacarthur 15:33 May 11, 2007

Right... here's a patch that works to scare off the optimiser in my build. With this patch applied, my mingw setup works correctly... Note that *both* mods seem to be necessary, that is marking "what" as volatile *and* modifying the conditional test. Can anybody else give this a shot and see how it works out? Also, can anyone check I haven't inadvertently broken the drawing of unfilled circles? Thanks... --- ../fl_vertex.cxx Fri May 11 23:12:59 2007 +++ src/fl_vertex.cxx Fri May 11 23:22:54 2007 @@ -106,7 +106,7 @@ static int p_size; static int n; -static int what; +volatile static int what; enum {LINE, LOOP, POLYGON, POINT_}; void fl_begin_points() {n = 0; what = POINT_;} @@ -302,7 +302,7 @@ int lly = (int)rint(yt-ry); int h = (int)rint(yt+ry)-lly; #ifdef WIN32 - if (what==POLYGON) { + if ((what==POLYGON) && (what!=LOOP)) { SelectObject(fl_gc, fl_brush()); Pie(fl_gc, llx, lly, llx+w, lly+h, 0,0, 0,0); } else

#21	ianmacarthur 05:36 May 13, 2007

Yes - it's an optimiser error. I've been staring at assembler listings all morning, and the test at line 305 of fl_vertex.cxx: if (what==POLYGON) { is simply being optimised out... Options seem to be to compile this file with no optimisation, which generates valid, but somewhat verbose code, or to try and scare off the optimiser so this test gets through intact, which is what my patch sems to do, albeit at some small impact on the efficiency of the generated code (but still better than no optimisation.) -- Ian

#22	matt 06:00 May 13, 2007

!: have you tried POLYGON==what instead of what==POLYGON? What happens if you give it the actual value of POLYGON instead? Could it be confusing POLYGON for something alse in a differen SCOPE? Maybe imported in one of the includes (try replacing POLYGON with FL_POLYGON everywhere). It might also be interesting to look at what the preprocessor made from the code before going into the compile stage. 2: If all the above fails and this is really a dirty error, what else is optimized out in our code? ;-)

#23	ianmacarthur 07:53 May 13, 2007

>!: have you tried POLYGON==what instead of what==POLYGON? Oh yes, and quite a variety of other variations on the theme, followed by lots of staring at assembler output to see what's changed. It did not help! > What happens if you give it the actual value of POLYGON instead? No change - the generated code just doesn't have the test. Although bizarrely it has the "jne" that would be testing the comparison, if it had bothered to do it..., but the conditional is not set due to a preceding load operation of another parameter. The test of "what" is simply gone! > Could it be confusing POLYGON for something else in a different SCOPE? Don't think so, but I changed the spelling of POLYGON, to no avail. > Maybe imported in one of the includes (try replacing POLYGON with > FL_POLYGON everywhere). It might also be interesting to look at what > the preprocessor made from the code before going into the compile stage. The pre-proc output looks correct to me, and it does not look like we are "overwriting" any symbol names or etc. > 2: If all the above fails and this is really a dirty error, what else > is optimized out in our code? ;-) I dread to think! Mind you, I tried to reproduce this error in a cut down test, but did not succeed, so it seems to be a very rare and peculiar failure... The error seems very sensitive to optimiser setting though. I think you (Matt) have cygwin installed - what do you get if you compile non-debug? Are you now seeing this error, too? FWIW, I still think my patch is a credible solution short-term, it seems to make the code do the "Right Thing" at minimal run-time cost. -- Ian

#24	ianmacarthur 08:14 May 13, 2007

OK, having said in my previous post that this bug is sensitive to optimisation levels, I've just had a trawl through the various assembler dumps I've got, and it looks as if the code *is* generated OK at both -O2 and -O3. It really does look like it's only -Os that is getting it wrong... Anyway, I just ran a full build from scratch at -O3 and it seems to be fine. Maybe that is a better patch? Make the default optimisation be -O2 or -O3 rather than -Os, for mingw/cygwin builds? Unfortunately, I don't know how to do that, autoconf I just don't grok. -- Ian

#25	ianmacarthur 08:40 May 13, 2007

And... here's a guess at a patch to configure.in to get the desired effect. Any good? I think we've reached the limits of my knowledge of autoconf, so this is the best I can do! I think it will make anu cygwin or mingw builds use -O3 but still allow the user to override the optimiser setting, and still allow other GCC varinats to use -Os instead. Hope this works! Seems to be OK for me, anyway. --- ../fltk-1.1/configure.in Sun May 13 16:35:04 2007 +++ ./configure.in Sun May 13 16:30:46 2007 @@ -611,6 +611,12 @@ DSOFLAGS="-mwindows $DSOFLAGS" LIBS="$LIBS -lole32 -luuid -lcomctl32 -lwsock32" OPTIM="$OPTIM" + if test "x$with_optim" != x; then + OPTIM="$with_optim $OPTIM" + else + OPTIM="-O3 $OPTIM" + with_optim="-O3" + fi if test x$enable_gl != xno; then AC_CHECK_HEADER(GL/gl.h,

#26	ianmacarthur 08:43 May 13, 2007

Oh - forgot to say... with the configure patch applied, the workaround I proposed for fl_vertex.cxx is no longer required. Cheers. I done now, -- Ian

#27	matt 02:04 May 14, 2007

OK, compiling "optimized", I get the same issue here: empty circles. I will change the build scripts to reduce the level of optimization for Cygwin onlt (maybe I can tie it to that particular gcc version). I have not looked at the patch yet, but thanks dso much for all the research! I will see how it fits in and release a "pre-final" hopefully today. As much as I appreciate the efforts of the Cygwin team, I have to say that FLTK for Cygwin has cost me more hours than any other subproject in FLTK. I do hope that they keep up their good work, but please try to stay as compatible as possible... .

#28	matt 05:22 May 14, 2007

Fixed in Subversion repository. Setting default optimization to O3 for the platforms affected. Thanks for all the work and the patches!!