Fixed text being dropped when the draw context stack overflows

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.

[fdesbiens]

Problem

guix_all_widgets_accordion_menu has been failing on master with Frame 12 is different since #158.

git bisect run names #158 (8a35f690, the issue #148 stack-corruption fix) as the first bad commit. That commit made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. For callers that push a nested context on the widget they are already drawing, purely to narrow the clipping rectangle to the client area, that turns a correct rendering into no rendering at all.

The multi-level accordion screen of the all_widgets demo nests widgets nine levels deep — multi_level_accordion → menu_list → mla_menu_1_accordion → menu_list → text_view_3 — and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked (gx_system_canvas_refresh.c:335 and :376). The eight slots of GX_MAX_CONTEXT_NESTING are therefore exhausted before _gx_multi_line_text_view_text_draw() can push its own, and the text is dropped.

The golden file records the correct rendering

Raising GX_MAX_CONTEXT_NESTING in a scratch build makes frame 12 match the existing golden file byte-for-byte. So the golden is the correct output and #158 introduced a visual regression: text GUIX had always drawn is now missing. Regenerating the golden would have blessed that permanently, which is why this PR fixes the code instead and leaves all golden data untouched.

Measured with gdb, one run of the test hits GX_DRAW_NESTING_EXCEEDED 68 times: 67 from _gx_widget_children_draw (not changed by #158 — it is cited there as the reference implementation, and it has always dropped the paint) and exactly 1 from _gx_multi_line_text_view_text_draw. One changed call site, one differing frame.

Fix

#158 conflated two things: "no context was pushed, so _gx_canvas_drawing_complete() must not be called" (correct) with "so nothing may be drawn" (not correct for a clip-only push).

When a widget initiates a nested context on itself just to narrow the clip, the caller's context is still the right context to draw through: it was created for the same widget, carries the same view list, and differs only in gx_draw_context_dirty. These call sites now narrow the caller's clipping rectangle, draw, and restore it:

context=_gx_system_current_draw_context;
saved_dirty=context->gx_draw_context_dirty;
_gx_utility_rectangle_overlap_detect(&saved_dirty, &client, &draw_area);
status=_gx_canvas_drawing_initiate(canvas, (GX_WIDGET*)text_view, &draw_area);
if (status==GX_DRAW_NESTING_EXCEEDED)
{
context->gx_draw_context_dirty=draw_area;
}
if ((status==GX_SUCCESS) || (status==GX_DRAW_NESTING_EXCEEDED))
{
... draw ...
if (status==GX_SUCCESS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
context->gx_draw_context_dirty=saved_dirty;
}
}
elseif (status==GX_NO_VIEWS)
{
_gx_canvas_drawing_complete(canvas, GX_FALSE);
}
else
{
/* GX_INVALID_MEMORY_SIZE and anything else also return before a context is pushed. */
}

_gx_canvas_drawing_complete() is still never called on overflow, so the stack corruption #158 fixed stays fixed. The non-overflow path is unchanged, which is why nothing else in the suite moves.

Applied to the four clip-only call sites:

File	Why it qualifies
gx_multi_line_text_view_text_draw.c	clip-only push on text_view; the reproduced regression
gx_multi_line_text_input_draw.c	clip-only push on input
gx_rich_text_view_text_draw.c	clip-only push on text_view
gx_single_line_text_input_draw.c	clip-only push on widget

Deliberately not changed:

File	Why not
gx_widget_block_move.c	a blit, not a clip refinement; its correct fallback is the dirty list, not a borrowed context
gx_radial_progress_bar_background_draw.c	initiates on a different canvas with who == GX_NULL; there is no caller context on that canvas to borrow

Tests

guix_canvas_draw_nesting_overflow_no_output (added by #158) covers overflow detection and state preservation. Nothing covered what a caller must render — the gap that let this regression through.

New: guix_canvas_draw_nesting_overflow_render_no_output. It fills the draw context stack on a real multi line text view, gives the widget a non-zero whitespace so the narrowed clip is strictly smaller than the widget clip, and asserts that

1. pixels are written at maximum nesting depth — the draw is not dropped;
2. the borrowed context comes back with its nesting count, context pointer and all four clip edges unchanged;
3. the byte checksum of the canvas matches the checksum from the same draw with a nested context available — overflow rendering is identical to normal rendering, not merely non-empty.

The checksum sums raw bytes of gx_canvas_memory, so the test is colour-depth agnostic and behaves the same in every build configuration. Confirmed to fail without the code change:

no pixels were written at maximum draw context nesting depth
Expected: 0x410a9, (266409) Got: 0x0 (0)
Guix Test: guix_canvas_draw_nesting_overflow_render_no_output......Failed!

Three of the four fixed call sites have no existing test that reaches the overflow path, so this is their only coverage.

Results

Configuration	Before	After
default_build_coverage	730/732	732/733
partial_canvas_support_build	7/7	7/7
dynamic_bidi_text_build	2/3	2/3, byte-identical output

guix_all_widgets_accordion_menu passes against the unmodified golden file. No golden data was regenerated.

The one remaining default_build_coverage failure, guix_ml_text_view_32bpp, is a separate pre-existing issue with a different cause (no nesting overflow occurs in it at all; #159 word wrapping is the suspect). guix_bidi_text_draw_32bpp in dynamic_bidi_text_build is also pre-existing and produces byte-identical output before and after this change.

Follow-up, not in this PR

The 67 _gx_widget_children_draw overflows are a separate, older defect: the demo's accordion screen needs a peak context depth of 10 (measured by instrumenting _gx_canvas_drawing_initiate()), while GX_MAX_CONTEXT_NESTING defaults to 8. Consequently six frames of guix_all_widgets_accordion_menu's golden data (15–20) record incompletely painted output — they stop matching as soon as the stack is deep enough for the children to be drawn.

Raising the default is well contained (at 12: 304 bytes of static RAM on a 32-bit target, six golden frames to regenerate, and guix_widget_children_draw to rewrite since it exists specifically to exceed the limit), but it changes a public default and checked-in golden data, so it is kept out of this fix.

Closes the regression introduced by #158.