STR #2016

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 2.0 | Post Text | Post File | SVN ⇄ GIT ]

STR #2016

Application:FLTK Library
Status:5 - New
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:Unassigned
Summary:Nasty logic error in Group::draw_child()
Version:2.0-current
Created By:aliazar
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files


Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 aliazar
15:40 Jul 30, 2008
N.B. although the problem is in src/Group.cxx, it has only manifested itself on Windows (MSVC) builds, probably because of differences in event management between window managers.

Exists thru current release 2.0.x-r6149

In Group::draw_child() there are two cases: either the child Widget 'w' is a Window or not.  The action for non-Window is 'w.draw()'.  The action for Window is 'fl_window_flush(&w)', which MAY NOT DRAW ANYTHING!  For example, if 'w' is not exposed or not 'visible_r()' then fl_window_flush() returns without drawing.  But Group::draw_child() unsets damage IN BOTH CASES unconditionally.  This is a logic error in the case where fl_window_flush() returns without drawing!

Since fl_window_flush() takes care of unsetting damage itself, my solution was to move the 'w.set_damage(0)' command into the 'else' block so that it only applies to the non-Window case.

The above description should make clear the logic flaw, but in case you're interested the context of the bug...

This error occured in the case of a TabGroup in which Widgets inside a hidden child (tab page) (containing Windows) were updated.  When the hidden child is shown by choosing its tab, its contents are not redrawn with the updated values.  Why?  Because a 'draw' event came down before exposure, triggered the Group::draw_child() from TabGroup::draw(), called fl_window_flush() which returned immediately without drawing because the window had 'wait_for_expose' set, at which point Group::draw_child() clears the damage flags so that when a legitimate draw event comes down after exposure, it does nothing because it thinks there is no damage.

This took me days to track down.  It is a one-line fix as described above.  I hope you will fix it for the next release.
 
 
#2 spitzak
16:07 Aug 04, 2008
I think the wait_for_expose is only needed for X11, or may not be needed at all.

Try taking out the test for wait_for_expose at run.cxx:639 and see if that makes it work on Windows.

If it does then some tests are needed to see if it is needed for X11 only, or could be deleted entirely.
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

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