STR #1656

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

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
Summary:fl_circle is filled on unix, open on windows
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:

Name/Time/Date Filename/Size top right image
#1 a.rburgers.quicknet
06:12 Apr 17, 2007
#2 a.rburgers.quicknet
06:13 Apr 17, 2007
#3 a.rburgers.quicknet
01:19 Apr 23, 2007
#4 a.rburgers.quicknet
01:20 Apr 23, 2007
#5 a.rburgers.quicknet
01:20 Apr 23, 2007
#6 a.rburgers.quicknet
12:55 May 02, 2007
#7 matt
13:55 May 02, 2007
#8 a.rburgers.quicknet
14:38 May 02, 2007
#9 a.rburgers.quicknet
14:38 May 02, 2007
#10 ianmacarthur
04:50 May 09, 2007
#11 ianmacarthur
04:50 May 09, 2007
#12 ianmacarthur
04:50 May 09, 2007
#13 ianmacarthur
12:33 May 11, 2007
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#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
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

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.

#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).

#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?


--- ../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;
 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.)
#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.

#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.
#25 ianmacarthur
08:40 May 13, 2007
And... here's a guess at a patch to 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/ Sun May 13 16:35:04 2007
+++ ./ Sun May 13 16:30:46 2007
@@ -611,6 +611,12 @@
         DSOFLAGS="-mwindows $DSOFLAGS"
         LIBS="$LIBS -lole32 -luuid -lcomctl32 -lwsock32"
+        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
#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,
#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!!
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.