fl_pop_clip: clip stack underflow! warning on X11

[Will B]

Hello again folks,

When run from the terminal, my app is spamming with 'fl_pop_clip: clip stack underflow!' warning messages.  This is happening when the code below is run:

/*
    cl = a VNC client structure
*/

int nBytesPerPixel = cl->format.bitsPerPixel / 8;

// create image surface
Fl_Image_Surface* surfImg = new Fl_Image_Surface(cl->width, cl->height);

// tell FLTK to draw onto the image surface from now on
surfImg->set_current();

// draw onto the image surface
fl_draw_image(
    static_cast<const uchar*>(cl->frameBuffer),
    0,
    0,
    cl->width,
    cl->height,
    nBytesPerPixel,
    0);

// tell FLTK to draw onto the screen from now on
Fl_Display_Device::display_device()->set_current();

// create RGB image from image surface image
Fl_RGB_Image* imgI = surfImg->image();

// set appropriate scale quality
if (itm->scalingFast == false)
    imgI->RGB_scaling(FL_RGB_SCALING_BILINEAR);

// scale down imgI image to imgC
Fl_Image* imgC = imgI->copy(app->vncViewer->w(), app->vncViewer->h());

// draw scaled image onto screen
imgC->draw(app->scroller->x(), app->scroller->y());

delete surfImg;
delete imgI;
delete imgC;

Any ideas what could be causing this message to repeatedly display?

Thank you!  :-)

Will Brokenbourgh

[Greg Ercolano]

On 04/20/17 19:32, Will B wrote:
> When run from the terminal, my app is spamming with 'fl_pop_clip: clip stack underflow!' warning messages. This is happening when the code below is run:

> [..]

> Any ideas what could be causing this message to repeatedly display?

Most likely fl_pop_clip() is called without a previously called fl_push_clip().

If your code makes any use of these two functions, check that the
'push' call precedes every 'pop'.

The clipping stack is much like any other stack; like in assembly language,
when you pop something off, an item has to have been pushed there first,
otherwise the pop will underflow the stack. (Similar to walking off the
end of an array)

If you aren't making use of these push/pop functions, then perhaps
it's a problem within FLTK, or your use of functions that manipulate
the clipping stick. In either case we might need to see a working example;
see if you can create a small compilable program to demonstrate the problem
and post it here.

[chris]

> When run from the terminal, my app is spamming with 'fl_pop_clip: clip
> stack underflow!' warning messages. This is happening when the code
> below is run:

>

> // create image surface
> Fl_Image_Surface*surfImg =newFl_Image_Surface(cl->width,cl->height);

>
> // tell FLTK to draw onto the image surface from now on
> surfImg->set_current();
>
> // draw onto the image surface
> fl_draw_image(

> static_cast<constuchar*>(cl->frameBuffer),

> 0,
> 0,
> cl->width,
> cl->height,
> nBytesPerPixel,
> 0);
>
> // tell FLTK to draw onto the screen from now on
> Fl_Display_Device::display_device()->set_current();
>
> // create RGBimage from image surface image

> Fl_RGB_Image*imgI =surfImg->image();

>
> // set appropriate scale quality
> if(itm->scalingFast ==false)
> imgI->RGB_scaling(FL_RGB_SCALING_BILINEAR);
>
> // scale down imgI image to imgC

> Fl_Image*imgC =imgI->copy(app->vncViewer->w(),app->vncViewer->h());

>
> // draw scaled image onto screen
> imgC->draw(app->scroller->x(),app->scroller->y());
>
> deletesurfImg;
> deleteimgI;
> deleteimgC;
> |
>

> Any ideas what could be causing this message to repeatedly display?

Try if this order of statements helps (i.e. read the image from the
surface before restoring the draw context):

// create RGBimage from image surface image
Fl_RGB_Image*imgI =surfImg->image();

[Albrecht Schlosser]

On 21.04.2017 11:13 Greg Ercolano wrote:
> On 04/20/17 19:32, Will B wrote:
>> When run from the terminal, my app is spamming with 'fl_pop_clip: clip stack underflow!' warning messages. This is happening when the code below is run:
>> [..]
>> Any ideas what could be causing this message to repeatedly display?

[ Greg's good explanation elided, see his post ]

> If you aren't making use of these push/pop functions, then perhaps
> it's a problem within FLTK, or your use of functions that manipulate
> the clipping stick. In either case we might need to see a working example;
> see if you can create a small compilable program to demonstrate the problem
> and post it here.

... and (if it might be a problem in FLTK) we need the exact FLTK
version the OP used and the platform (Windows, Linux, compiler/toolchain
at least).

[Albrecht Schlosser]

On 21.04.2017 16:59 Albrecht Schlosser wrote:

> ... and (if it might be a problem in FLTK) we need the exact FLTK
> version the OP used and the platform (Windows, Linux, compiler/toolchain
> at least).

Okay, I missed "on X11" in the subject, so it's clearly on X11, but we
still need the FLTK version and also relevant configure options (Xft and
Pango (in FLTK 1.4) come to mind).

[Will B]

On Friday, April 21, 2017 at 2:13:09 AM UTC-7, Greg Ercolano wrote:

        Most likely fl_pop_clip() is called without a previously called fl_push_clip().

        If your code makes any use of these two functions, check that the
        'push' call precedes every 'pop'.

        The clipping stack is much like any other stack; like in assembly language,
        when you pop something off, an item has to have been pushed there first,
        otherwise the pop will underflow the stack. (Similar to walking off the
        end of an array)

        If you aren't making use of these push/pop functions, then perhaps
        it's a problem within FLTK, or your use of functions that manipulate
        the clipping stick. In either case we might need to see a working example;
        see if you can create a small compilable program to demonstrate the problem
        and post it here.

Hi Greg,

I'm not using those clip functions, just what you see in my example code.

I'll try to make a compilable program when I have a few minutes.

Thanks! :-)

Will Brokenbourgh

[Will B]

On Friday, April 21, 2017 at 7:38:30 AM UTC-7, chris wrote:

Try if this order of statements helps (i.e. read the image from the
surface before restoring the draw context):

// create RGBimage from image surface image
Fl_RGB_Image*imgI =surfImg->image();

// tell FLTK to draw onto the screen from now on
Fl_Display_Device::display_device()->set_current();

Hi Chris,

I'll give it a try and let you all know.  Thanks!  :-)

Will Brokenbourgh

[Will B]

On Friday, April 21, 2017 at 8:03:08 AM UTC-7, Albrecht Schlosser wrote:

Okay, I missed "on X11" in the subject, so it's clearly on X11, but we
still need the FLTK version and also relevant configure options (Xft and
Pango (in FLTK 1.4) come to mind).

Hi,

It's 1.3.3 on Salix 64-bit.  I don't know what configuration options they used, unfortunately.

Sincerely,

Will Brokenbourgh

[Albrecht Schlosser]

On 21.04.2017 17:07 Will B wrote:
> On Friday, April 21, 2017 at 8:03:08 AM UTC-7, Albrecht Schlosser wrote:
>>
>> Okay, I missed "on X11" in the subject, so it's clearly on X11, but we
>> still need the FLTK version and also relevant configure options (Xft
>> and Pango (in FLTK 1.4) come to mind).
>

> It's 1.3.3 on Salix 64-bit. I don't know what configuration options
> they used, unfortunately.

Well, if it's 1.3.3, then please try to build FLTK 1.3.4 yourself and
use this. It is very likely possible that this particular issue was
fixed in 1.3.4. Further fixes will be done in 1.4.0, so trying a recent
snapshot or the current svn/git development version would be worth a try.

Chasing bugs in FLTK 1.3.3 is not worth the effort, but if you can post
compileable full source code that shows the bug in 1.3.4 or 1.4.0 then
we should be able to find and fix it. Thanks for your efforts.

Note: Building FLTK yourself is pretty much straightforward and several
FLTK versions can easily be used on the same system. Just keep in mind
not to _install_ your self-built FLTK version(s). You can then point
your compiler/linker to the build directory of your local FLTK version
and build with that one. FLTK 1.3.x and FLTK 1.4.0 are API compatible so
this shouldn't be a problem.

[Will B]

On Friday, April 21, 2017 at 8:25:53 AM UTC-7, Albrecht Schlosser wrote:

Well, if it's 1.3.3, then please try to build FLTK 1.3.4 yourself and
use this. It is very likely possible that this particular issue was
fixed in 1.3.4. Further fixes will be done in 1.4.0, so trying a recent
snapshot or the current svn/git development version would be worth a try.

Chasing bugs in FLTK 1.3.3 is not worth the effort, but if you can post
compileable full source code that shows the bug in 1.3.4 or 1.4.0 then
we should be able to find and fix it. Thanks for your efforts.

Note: Building FLTK yourself is pretty much straightforward and several
FLTK versions can easily be used on the same system. Just keep in mind
not to _install_ your self-built FLTK version(s). You can then point
your compiler/linker to the build directory of your local FLTK version
and build with that one. FLTK 1.3.x and FLTK 1.4.0 are API compatible so
this shouldn't be a problem.

Yes, FLTK is exceedingly easy to compile.  1.3.4-1 shows this issue too as I've compiled it and installed on other OSs.  I'll try to come up with an example as soon as I can.

Thanks,  :-)

Will Brokenbourgh

[Will B]

On Friday, April 21, 2017 at 7:38:30 AM UTC-7, chris wrote:

Try if this order of statements helps (i.e. read the image from the
surface before restoring the draw context):

// create RGBimage from image surface image
Fl_RGB_Image*imgI =surfImg->image();

// tell FLTK to draw onto the screen from now on
Fl_Display_Device::display_device()->set_current();

Hi again Chris,

Your suggestion fixed the problem!  Thank you! :-)

Thanks,

Will Brokenbourgh

[Greg Ercolano]

Great; glad a solution (or workaround?) is found.

Chris/Will, is there anything we should change in either the code
or the docs to help prevent others running into this in the future?

I'm not myself familiar with this particular functionality,
so I'm wondering if we have sufficient docs/examples showing
how to use this, or if the internals need to be tweaked to prevent this.

Or are the docs/examples/fltk code fine as it stands for this issue?

[Will B]

On Friday, April 21, 2017 at 10:45:09 AM UTC-7, Greg Ercolano wrote:

        Great; glad a solution (or workaround?) is found.

        Chris/Will, is there anything we should change in either the code
        or the docs to help prevent others running into this in the future?

        I'm not myself familiar with this particular functionality,
        so I'm wondering if we have sufficient docs/examples showing
        how to use this, or if the internals need to be tweaked to prevent this.

        Or are the docs/examples/fltk code fine as it stands for this issue?

 
Hi Greg,

I'm not sure how it should be presented to users in the documentation, but moving the Fl_Display_Device::display_device()->set_current() *right* before the first screen draw (and after the last draw to the Fl_Image_Surface) definitely eliminated the warnings. 

I didn't see any actual problems with my graphical output when the warnings were being displayed, but I think Fl_Graphics_Driver::pop_clip() in fl_rect.cxx might be looking at the wrong thing if display_device()->set_current() is called too early.  I'm not a graphics guru, so I will give this over to you experts. :-)

Sincerely,

Will Brokenbourgh

[chris]

>
> Great; glad a solution (or workaround?) is found.
>

I think this order of statements is only required with FLTK 1.3.4, no
longer with 1.4.

> I'm not myself familiar with this particular functionality,
> so I'm wondering if we have sufficient docs/examples showing
> how to use this, or if the internals need to be tweaked to prevent this.
>
> Or are the docs/examples/fltk code fine as it stands for this issue?

My feeling is no. There could be more (dedicated) examples and perhaps
the documentation about "offscreen drawing" could also mention the new
possibilites of Fl_Image_Surface.

[Greg Ercolano]

On 04/21/17 12:29, chris wrote:
>>
>> Great; glad a solution (or workaround?) is found.
>>
>
> I think this order of statements is only required with FLTK 1.3.4, no
> longer with 1.4.

I see.

>> I'm not myself familiar with this particular functionality,
>> so I'm wondering if we have sufficient docs/examples showing
>> how to use this, or if the internals need to be tweaked to prevent this.
>>
>> Or are the docs/examples/fltk code fine as it stands for this issue?
>
> My feeling is no. There could be more (dedicated) examples and perhaps
> the documentation about "offscreen drawing" could also mention the new
> possibilites of Fl_Image_Surface.

Good to know, and is why I asked.

I've just made STR #3379 requesting documentation improvements
mentioned in this thread, and the other thread today requesting
code examples on event handling.

[Will B]

As requested, I have made a compilable example which outputs the warning to the terminal:

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_draw.H>
#include <FL/Fl_Image_Surface.H>

void draw (void*)
{
    // create image surface
    Fl_Image_Surface* surfImg = new Fl_Image_Surface(1024, 740);

    //// tell fltk to draw onto the image surface from now on
    surfImg->set_current();

    fl_rectf(0, 0, 1024, 740, 100, 255, 100);

    //// tell fltk to draw onto the screen from now on
    Fl_Display_Device::display_device()->set_current();

    //// create rgb image from image surface image

    Fl_RGB_Image* imgI = surfImg->image();

    //// set appropriate scale quality
    imgI->RGB_scaling(FL_RGB_SCALING_BILINEAR);

    //// scale down imgI image to imgC
    Fl_Image* imgC = imgI->copy(400, 300);

    //// draw scaled image onto screen
    imgC->draw(400, 300);

    delete surfImg;
    delete imgI;
    delete imgC;

    Fl::repeat_timeout(1.0, draw);
}


/* main program */
int main(int argc, char **argv)
{
    Fl_Window *window = new Fl_Window(1024, 740);
    window->end();
    window->show(argc, argv);

    Fl::add_timeout(1.0, draw);

    return Fl::run();
}

Thanks,  :-)

Will Brokenbourgh

[Greg Ercolano]

On 04/21/17 13:50, Will B wrote:
> As requested, I have made a compilable example which outputs the warning to the terminal:

Great, much thanks.

I can confirm on Linux/X11:

On 1.3.x svn current, it prints the "fl_pop_clip: clip stack underflow!"
warnings once per second, and draws a green rectangle in a gray window.

On 1.4.x svn current, there's no warning, but only draws a gray window.
(No green rectangle)

However, if I adjust the code as per Chris's suggestion:

On 1.3.x svn current, no warnings, and draws the green rectangle.
On 1.4.x svn current, no warnings, and draws the green rectangle.

So sounds like Chris's suggestion on re-ordering is the way to go,
as this works consistently on both versions of FLTK.

I assume this is the intended use case we should document.
Awaiting info from the devs familiar with the image surface abstraction,
as I am not.

[Ian MacArthur]

Yes, I think I agree; I think the only example we have of offscreen drawing is my old fl_offscreen test sample, which isn’t ideal and does not address the Fl_Image_Surface case at all.

That said, I’m not sure I know enough about the use of Fl_Image_Surface to do it justice! 

As an aside, reading this thread rang a bell with me; when I was testing this example:

https://groups.google.com/d/msg/fltkgeneral/GcUlvKpKhj0/BSlD9BegAgAJ

on my X11 boxes, I think on at least one case I did see clip stack warnings from that code; though I did not pursue them (I was in the middle of “other stuff”...)

Which is “interesting” I guess, at least for me!

I wonder if I shuffle this around as Chris suggest, that would help? And whether that might also (long shot) be they key to getting that example to work on OSX (where it is currently not working at all... Hmm.)

Worth at try at any rate!

[Ian MacArthur]

On Sat Apr 22 2017 22:11:32, Ian MacArthur wrote:

As an aside, reading this thread rang a bell with me; when I was testing this example:

https://groups.google.com/d/msg/fltkgeneral/GcUlvKpKhj0/BSlD9BegAgAJ

on my X11 boxes, I think on at least one case I did see clip stack warnings from that code; though I did not pursue them (I was in the middle of “other stuff”...)

Which is “interesting” I guess, at least for me!

I wonder if I shuffle this around as Chris suggest, that would help? And whether that might also (long shot) be they key to getting that example to work on OSX (where it is currently not working at all... Hmm.)

Worth at try at any rate!

Meh! Tried that (re-ordering the reading of the image wrt the restoring of the current context) and it does seem to resolve the clip issue I was seeing on X11 at times.

But... it does not resolve the issue with my test code on OSX.

Basically, looks like my code just Doesn’t Work on OSX, and I can’t see what I’ve done wrong. 

Maybe need to see if Manolo can spot something? He’s good at these OSX things!

[Albrecht Schlosser]

On 22.04.2017 00:48 Greg Ercolano wrote:
> On 04/21/17 13:50, Will B wrote:
>> As requested, I have made a compilable example which outputs the warning to the terminal:
>
> Great, much thanks.
>
> I can confirm on Linux/X11:
>
> On 1.3.x svn current, it prints the "fl_pop_clip: clip stack underflow!"
> warnings once per second, and draws a green rectangle in a gray window.
>
> On 1.4.x svn current, there's no warning, but only draws a gray window.
> (No green rectangle)

In the original code version Fl_Image_Surface::image() is called while
the current drawing context is set to the screen driver. This failed to
read the image from the the image surface surfImg in FLTK 1.4 whereas it
obviously (kinda) "works" in FLTK 1.3 with the 'clip stack underflow'
warning.

IMO Fl_Image_Surface::image() _must_ work always independent of the
current drawing context, and the fix was pretty straightforward in FLTK
1.4 (svn r12221):

Fl_RGB_Image* Fl_Xlib_Image_Surface_Driver::image()
{
+ push_current(this);
unsigned char *data = fl_read_image(NULL, 0, 0, width, height, 0);
+ pop_current();
...

@Manolo: please feel free to change this fix if you can find a better
way to do it. I thought of calling read_win_rectangle(..) directly but
couldn't find a way to set up the correct driver context. I'm also
afraid that the same issue might be on other platforms, but I didn't
test any other platforms yet.

> However, if I adjust the code as per Chris's suggestion:
>
> On 1.3.x svn current, no warnings, and draws the green rectangle.
> On 1.4.x svn current, no warnings, and draws the green rectangle.

This is a workaround that works for FLTK 1.3 and is no longer necessary
for FLTK 1.4 since r12221.

Thanks to Chris for the hint, BTW.

> So sounds like Chris's suggestion on re-ordering is the way to go,
> as this works consistently on both versions of FLTK.

Since this is no longer necessary and was certainly not intended I
wouldn't want to recommend it.

> I assume this is the intended use case we should document.
> Awaiting info from the devs familiar with the image surface abstraction,
> as I am not.

As I wrote above, Fl_Image_Surface::image() must work no matter what the
current drawing context is. My modified code shows another situation
where surface creation and the draw() method that extracts the image are
separated. This version works well in FLTK 1.4 (r12221).

Unfortunately this will not work in FLTK 1.3 and since we can't change
the docs I don't know what to do (other than fix it and issue 1.3.5).

Here's the modified example code:

-- snip --

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_draw.H>
#include <FL/Fl_Image_Surface.H>

Fl_Image_Surface* surfImg = 0;

// Create image surface and draw a green rectangle onto it
void create_image (void)
{
// create image surface

surfImg = new Fl_Image_Surface(1024, 740);

//// tell fltk to draw onto the image surface from now on
surfImg->set_current();

fl_rectf(0, 0, 1024, 740, 100, 255, 100);

//// tell fltk to draw onto the screen from now on
Fl_Display_Device::display_device()->set_current();
}

// read the image surface and draw it on the screen (window)
void draw (void*)
{

//// create rgb image from image surface image
Fl_RGB_Image* imgI = surfImg->image();

//// set appropriate scale quality
imgI->RGB_scaling(FL_RGB_SCALING_BILINEAR);

//// scale down imgI image to imgC
Fl_Image* imgC = imgI->copy(400, 300);

//// draw scaled image onto screen
imgC->draw(400, 300);

delete imgI;
delete imgC;

Fl::repeat_timeout(1.0, draw);
}

/* main program */
int main(int argc, char **argv)
{
Fl_Window *window = new Fl_Window(1024, 740);
window->end();
window->show(argc, argv);

Fl::add_timeout(1.0, draw);

create_image(); // notice: create image surface here

return Fl::run();
}
-- snip --

[Manolo]

This problem should be fixed now in FLTK 1.4 with r.12222.
This fix is Albrecht's, slightly modified so it is platform-independent.

@Ian: the reason why the test program (which draws a green rectangle)
doesn't work under MacOS X is that it attempts to draw to a window without having
made this window current before. The X11 platform is such that this works,
but, under MacOS X, drawing absolutely requires Fl_Window::make_current()
when drawing is not performed within the window's draw() function.
Add
  Fl::first_window()->make_current();
just before this statement
  imgC->draw(400, 300);
and the test program works cross-platform.