[fltk.bugs] [LOW] STR #2943: Incorrect drawing of rounded box

2013-04-03 Thread Nikita Egorov
DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2943
Version: 1.3-current


If size of widget is quite small then FLTK draws incorrect rounded box, all
four corners are different (upper fig. on the attached picture). 
I investigated the issue and found out a few things: to fix it first we
need to do mathematically correct rounding of coordinates. In other words,
instead fl_vertex(x,y) must be fl_vertex(x+0.5,y+0.5) (second fig.). In
fact, I suppose the rounding of coordinates is wider problem in FLTK.

Second, rbox will draw tidy corners only if size of their radius is even
number (third fig.).

And the latest, I rarely used rounded box because of ugly appearance
(IMHO). On the contrary, often I needed straight box but without sharp
corners. Setting the RS (max radius) to small value (2..6) gives me what I
want.(fourth fig.) Maybe, something like RS should be part of widget
properties or at least it would be mentioned in docs as customising point?


Link: http://www.fltk.org/str.php?L2943
Version: 1.3-current

rounded_box.tar.gz
Description: Binary data
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


[fltk.bugs] Mac OS X Fl_Gl_Window bugs

2013-04-03 Thread Lynn Quam
I have found two major bugs in the Mac OS X implementation of Fl_Gl_Window.  I 
will report the bugs in two separate postings.

The first bug occurs with overlays on Fl_Gl_Windows.  If either the OpenGL view 
transform or model transform are other than identity, then the code in 
Fl_Gl_Window::swap_buffers calling glCopyPixels to copy the GL_BACK to GL_FRONT 
has the wrong glRasterPos.

I have code to fix this bug.

Since I have not previously reported FLTK bug fixes, I would like to know the 
procedure that I should use.


___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


[fltk.bugs] Mac OS X Fl_Gl_Window bugs

2013-04-03 Thread Lynn Quam
The Mac OS X Fl_Gl_Window implementation has a serious bug in the code for 
Fl_Gl_Window::make_current when Fl_Windows are nested.  The computation for the 
x and y values of the xywh array passed to aglSetInteger(context_, 
AGL_BUFFER_RECT, xywh) does not take this nesting into account, causing the 
Gl_Window drawing area to be incorrectly placed inside the main window.

I have code to fix this bug.

Since I have not previously reported FLTK bug fixes, I would like to know the 
procedure that I should use.

___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


Re: [fltk.bugs] Mac OS X Fl_Gl_Window bugs

2013-04-03 Thread Greg Ercolano
On 04/03/13 18:34, Lynn Quam wrote:
 Since I have not previously reported FLTK bug fixes, I would like
 to know the procedure that I should use.

Hi Lynn,

Go to the main fltk.org page and click on 'Bugs  Features', and then 
click
Submit Bug or Feature Request, and follow the instructions from there.

When you create a trouble report, you'll be able to enter text and
attach things like patches, screenshots, etc.

If you have a fix, best to supply it as a patch, either with
'diff -Naur', or 'svn diff'
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs


Re: [fltk.bugs] Mac OS X Fl_Gl_Window bugs

2013-04-03 Thread Lynn Quam
 I have found two major bugs in the Mac OS X implementation of Fl_Gl_Window.  
 I will report the bugs in two separate postings.

 The first bug occurs with overlays on Fl_Gl_Windows.  If either the OpenGL 
 view transform or model transform are other than identity, then the code in 
 Fl_Gl_Window::swap_buffers calling glCopyPixels to copy the GL_BACK to 
 GL_FRONT has the wrong glRasterPos.

 I have code to fix this bug.

 Since I have not previously reported FLTK bug fixes, I would like to know the 
 procedure that I should use.




I forgot to mention that this problem is only triggered if some OpenGL code 
causes the glRasterPos to be changed from the bottom left corner of the 
Gl_Window.  In my case, the application code called gl_draw(const char* str, 
int n) to draw a string into the Gl_Window, which changes the glRasterPos.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs