| | [ 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: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #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. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
