| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #765
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | MacOS |
|---|
| Summary: | Polygons are drawn differently on OSX(QD) |
|---|
| Version: | 1.1-current |
|---|
| Created By: | Portale |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1.7 (SVN: v4154) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | Portale
01:01 Mar 18, 2005 |
| The fl_polygon() paints the polygons in a slightly different way on OSX, QuickDraw. There is in most cases missing one pixelline on the left and bottom of the polygon.
Polygons are used in many Widgets (Fl_Scrollbar, Fl_Choice, etc.).
This STR may seem pedantic, but if I use an automation/test tool like Eggplant, it makes the life easier if the GUI looks exactly the same on every Paltform. Furthermore it is a question of aesthetics.
A patch proposal is attached.
The attached image illustrates the current differences between OSX and Windows before and after the proposed patch.
Regards,
Alessandro Portale | |
| |
| #2 | matt
01:53 Mar 18, 2005 |
| Thank you very much! This is not pedantic at all, but a very neccessary fix. I did some testing for some of the drawing code, but never came around to do for the polygon code. Thanks for finding it. I will copy it over some time today! | |
| |
| #3 | matt
01:53 Mar 18, 2005 |
|
| |
| |
| #4 | wilson.afn
05:31 Mar 18, 2005 |
| Although I examined Allesandro's patch in its larger context, a peek at his screenshots has me a little concerned. It appears his fix makes correctly-functioning OSX rendering work like the malfunctioning Windows hack.
This Windows bug is benign when rendering isolated little triangles inside widgets, it is not nearly so pretty when rendering abutting polygon (e.g., on a surface mesh). There, it is important that the 'gons include their boundary on one "side" or another and exclude their boundary on the opposite side. The crude, "Coloring book fill" method of Windows greatly complicates anything but simple-minded cartoon applications.
| |
| |
| #5 | Portale
07:27 Mar 18, 2005 |
| Hi wilson.afn,
are you concerned about the extra "FramePoly" call? I am not really happy with that, either, but also for X "XDrawLines" is called after filling the polygon. I don't know the history but can immagine that this was done in order to overcome Windows special way of drawing filled polygons.
Since only the fl_polygon() functions for filling 3 or 4 sided polygons are concerned, it seems not so critical to me.
fl_begin_polygon(), fl_end_polygon() fl_begin_complex_polygon() fl_end_complex_polygon() are still working like before.
With the "FramePoly", OSX now draws 3 or 4 sided filled polygons like X and Windows (in the tests I did). But it surely should be tested with other fl_polygon() intensive applications. Does anybody know some? I would test them on the different platforms.
Regards,
Alessandro | |
| |
| #6 | Portale
15:06 Mar 18, 2005 |
| I did some more tests and compared the screenshots of many FLTK Test programs that I built on OSX (wit hthe patch), Linux and Winodws. I blended them together in "difference" mode in a graphical app, to see any singe pixel difference. -> Whereever polygons are drawn via fl_polygon(), now everything is exactly the same on all three platforms.
I am sure that fl_polygon() wasn't ever usable or used for drawing abutting polygons on Windows or X. In the X implementation the behaviour of Windows is actually emulated by calling "XDrawLines()" in order to be consistent (it is this way since ages, I guess). The developers are used to the fact and may use other polygon routines.
Microsoft documents their "Polygon()" routine like this:
"The Polygon function draws a polygon consisting of two or more vertices connected by straight lines. The polygon is _outlined_ by using the current pen and filled by using the current brush and polygon fill mode."
So, OSXs' fl_polygon() should do the same in order to give the same results as the other systems do since years.
Concern: somebody who wrote and tested an FLTK application exclusively on the Mac and relied on the abutting (I love this word) polygon, after the patch could have trouble. | |
| |
| #7 | matt
03:49 Mar 21, 2005 |
| Fixed in Subversion repository.
| |
[ Return to Bugs & Features ]
|
| |
