Fl_Double_Window Flickering while resizing

401 views
Skip to first unread message

André Miranda

unread,
Sep 25, 2013, 11:01:38 PM9/25/13
to fltkg...@googlegroups.com
I'm facing a strange problem, when a window is rendering a png image, while resizing it flickers a lot and displays artifacts.
Here is an example: http://pastebin.com/KRrg8gSN

Resize the window multiple times to see the flickering and artifacts.
Comment out the line #99 or set the image depth to 1 at line #98 and the flicker/artifacts are gone.

I've tried Fl::visual but it doesn't help.

I've also noticed that this problem doesn't affect Windows.
My setup is Archlinux 64-bit and FLTK 1.3.2 was built using system's libpng(1.6.5)

Thanks in advance!

Greg Ercolano

unread,
Sep 26, 2013, 1:10:18 AM9/26/13
to fltkg...@googlegroups.com
On 09/25/13 20:01, Andr� Miranda wrote:
> I'm facing a strange problem, when a window is rendering a png image, while resizing it flickers a lot and displays artifacts.
> Here is an example: http://pastebin.com/KRrg8gSN

Hmm, can't replicate on Sci Linux 6.3 on a Mac Mini with
1.3.x svn, default build.

Absolutely smooth and no artifacts anywhere in the window
as its resizing.

> My setup is Archlinux 64-bit and FLTK 1.3.2 was built using system's libpng(1.6.5)

I tried 1.3.2 as well using the OS's libpng 1.2.49; same result,
no artifacts.

Sounds like it could be graphics driver related.

1) what kind of graphics card on your system?
2) anything unusual about your platform? (i.e. embedded?)
3) do PNG images loaded into firefox flicker when you resize?

Someone else complained of artifacts with 1.3.x on a particular
graphics card -- they said it worked OK when using FLTK 3.x.
Even though FLTK 3.x is not even alpha stage yet, you might try it
just to see if the problem goes away?


MacArthur, Ian (Selex ES, UK)

unread,
Sep 26, 2013, 5:54:19 AM9/26/13
to fltkg...@googlegroups.com

> Sounds like it could be graphics driver related.

Yup, I was going to say it sounds like a graphics driver issue: certainly, in my testing I have seen some weird behaviours that were...

I'm not sure what drivers Arch ship, but I've certainly had issues with the nouveau driver, that went away when I switched to Nvidia's closed-binary driver instead (which id also orders of magnitude faster too, of course...!)




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

André Miranda

unread,
Sep 30, 2013, 7:49:29 PM9/30/13
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Thanks for the replies and sorry about the delay(while joining this group I forgot to mark the "keep me updated" option).


1) what kind of graphics card on your system?
Nvidia GTX 460, stock settings and nvidia closed-source driver version 325.15


2) anything unusual about your platform? (i.e. embedded?)
Nothing special, Arch Linux was installed following the official guide.
Besides the graphics card already mentioned, my PC is an average desktop: Intel Core2Duo, 6GB DDR2, Gigabyte Motherboard...


3) do PNG images loaded into firefox flicker when you resize?
Nope, I tested using the same PNG which as "marshaled" on the test case. Firefox 24 stable.

I forgot to mention, I my DE is stock Xfce(using Xfwm).

Tomorrow I'll play with another Distro here on my PC, or even my notebook, and see what happens.
If I can build, I'll try FLTK3 too.

Once thank you all.

Greg Ercolano

unread,
Sep 30, 2013, 9:15:21 PM9/30/13
to fltkg...@googlegroups.com
On 09/30/13 16:49, Andr� Miranda wrote:
> I forgot to mention, I my DE is stock Xfce(using Xfwm).

Can you try one of the other window managers that 'comes with',
either gnome, kde, or some other.

I can't really think why the window manager might affect
our double buffering code though.

> Tomorrow I'll play with another Distro here on my PC,
> or even my notebook, and see what happens.

I'd be surprised if the problem followed to another machine.

Different distro might affect it if the driver is different,
but I'd think the problem would follow the driver. (or driver config)

You might try fiddling with the driver options for acceleration.

> If I can build, I'll try FLTK3 too.

Ya, that'd be interesting.

If the problem disappears with FLTK3 then that would really
seem to point to 'something' we're doing wrong in 1.3.


André Miranda

unread,
Sep 30, 2013, 11:29:12 PM9/30/13
to fltkg...@googlegroups.com, erco_...@seriss.com
Ok, downloaded FLTK3 from SVN, built and the RGB_Image demo does the same flickering, so we can rule out this supposition...
Tomorrow I'll tell you what happened on another distro/machine...

On Monday, September 30, 2013 10:15:21 PM UTC-3, Greg Ercolano wrote:

André Miranda

unread,
Oct 1, 2013, 11:10:28 PM10/1/13
to fltkg...@googlegroups.com
On 09/30/13 22:15, Greg Ercolano wrote:
> Can you try one of the other window managers that 'comes with', either
> gnome, kde, or some other. I can't really think why the window manager
> might affect our double buffering code though.
> I'd be surprised if the problem followed to another machine. Different
> distro might affect it if the driver is different, but I'd think the
> problem would follow the driver. (or driver config) You might try
> fiddling with the driver options for acceleration.

I have installed Enlightenment17 here on Arch and no problems occurred.
I ran LinuxMint 15 Cinnamon Edition on a Live Session and no problems
occurred.
I ran Xubuntu 13.04 on a Live Session(Using Noveau drivers by default)
and the same problems have ocurred.
> Ya, that'd be interesting. If the problem disappears with FLTK3 then
> that would really seem to point to 'something' we're doing wrong in 1.3.
As I have already stated, the same problem happens using FLTK3.

It seems clear to me that it's a problem related to Xfce/Xfwm. I've
tried to disable to Xfwm compositor, but no success.
What else can I do to track down this problem?

Note: In Xfce and E17, a FLTK window is, in some places like the alt-tab
selector, labelled as "FLTK" instead of its title. Is this behaviour known?

Greg Ercolano

unread,
Oct 2, 2013, 2:00:42 AM10/2/13
to fltkg...@googlegroups.com
On 10/01/13 20:10, Andr� Miranda wrote:
> On 09/30/13 22:15, Greg Ercolano wrote:
>> Can you try one of the other window managers that 'comes with', either
>> gnome, kde, or some other. I can't really think why the window manager
>> might affect our double buffering code though.

> I have installed Enlightenment17 here on Arch and no problems occurred.
> I ran LinuxMint 15 Cinnamon Edition on a Live Session and no problems
> occurred.
> I ran Xubuntu 13.04 on a Live Session(Using Noveau drivers by default)
> and the same problems have ocurred.

Interesting.

Great that you've been able to supply us with this..
seems to point to a window manager specific behavior.

How it's manifesting I'm not exactly sure, but I could imagine that
during app resizing (which the window manager handles), the wm could
either be disabling double buffering during the resize/redraw operations,
or perhaps it's drawing a rectangle of the window in single buffer mode
over the app, then the app is drawing back over that, causing the flicker.

One thing to check too; perhaps the window manager specs have changed
in interesting ways where perhaps FLTK is being sent hints from the
window manager that we should respond to and are perhaps not. Like I
could maybe see how there might be an event that requests from FLTK
if the app is double buffered or single buffered so that the window
manager could handle resizing in some special way that helps it avoid
artifacts.. and because we're not responding to that, it's defaulting
to behavior that simply 'looks wrong'.

This is all just guessing on my part, I have no idea what might be
the problem. I guess it would help if I could see the effect, as there
might be something about the artifact that gives away the behavior.
For instance, if the 'flicker' is where the entire window changes
to white or gray briefly, then back to the app's content, which might
indicate the wm drawing a rectangle over the window area before the
app can redraw itself.

Hopefully some of our other devs can chime in that knows more about this.
I'm just acting as 'tier 1 support' here ;)

> It seems clear to me that it's a problem related to Xfce/Xfwm. I've
> tried to disable to Xfwm compositor, but no success.
> What else can I do to track down this problem?

Well, I could see trying to trace the X window operations.

I could also see trying to trace all window manager events going
in/out of FLTK, to see if maybe we're not handling something we
should be (such as some kind of request asking FLTK if the app
is in single buffer or double buffer mode.. that kind of thing)

I'd suggest looking at the FLTK code that handles window manager events,
and compare that to the Xfce code that generates events during resizing.

Also, checking into the latest window manager specs
(I think from opendesktop.org?) to see if there's anything new
that FLTK should be watching for; wm specs are constantly evolving.

> Note: In Xfce and E17, a FLTK window is, in some places like the alt-tab
> selector, labelled as "FLTK" instead of its title. Is this behaviour known?

Hmm, try setting the window's xclass() to see if it solves that.
e.g. yourwin->xclass("Some text")
It's separate from the window title.

André Miranda

unread,
Oct 2, 2013, 7:45:54 PM10/2/13
to fltkg...@googlegroups.com
On 10/02/13 03:00, Greg Ercolano wrote:
> This is all just guessing on my part, I have no idea what might be the
> problem. I guess it would help if I could see the effect, as there
> might be something about the artifact that gives away the behavior.
> For instance, if the 'flicker' is where the entire window changes to
> white or gray briefly, then back to the app's content, which might
> indicate the wm drawing a rectangle over the window area before the
> app can redraw itself. Hopefully some of our other devs can chime in
> that knows more about this. I'm just acting as 'tier 1 support' here ;)
Here you are: http://www.youtube.com/watch?v=YI9pREHMWIM

> Well, I could see trying to trace the X window operations.
>
> I could also see trying to trace all window manager events going
> in/out of FLTK, to see if maybe we're not handling something we
> should be (such as some kind of request asking FLTK if the app
> is in single buffer or double buffer mode.. that kind of thing)
>
> I'd suggest looking at the FLTK code that handles window manager events,
> and compare that to the Xfce code that generates events during resizing.
>
> Also, checking into the latest window manager specs
> (I think from opendesktop.org?) to see if there's anything new
> that FLTK should be watching for; wm specs are constantly evolving.
hummm, all this stuff it's beyond my knowledge... but I'll give it a try
during this week.
I'll also poke the xfce devs to see if they might help.

>> Note: In Xfce and E17, a FLTK window is, in some places like the alt-tab
>> selector, labelled as "FLTK" instead of its title. Is this behaviour known?
> Hmm, try setting the window's xclass() to see if it solves that.
> e.g. yourwin->xclass("Some text")
> It's separate from the window title.
It does work, thank you!

André Miranda

unread,
Oct 8, 2013, 10:17:49 PM10/8/13
to fltkg...@googlegroups.com, erco_...@seriss.com
I took a look at Xfce code, but all this X11 related code seems cryptic to me.
Here are the code parts that might be related to this problem:
http://git.xfce.org/xfce/xfwm4/tree/src/moveresize.c#n1620
http://git.xfce.org/xfce/xfwm4/tree/src/compositor.c#n2252

On FLTK side, the Double_Window seems to use a lot of something called XDBE, which might be related to this problem(I don't know, it's just a guess):
http://seriss.com/public/fltk/fltk/branches/branch-1.3/src/Fl_Double_Window.cxx

Anybody else?

MacArthur, Ian (Selex ES, UK)

unread,
Oct 9, 2013, 4:32:24 AM10/9/13
to fltkg...@googlegroups.com

Oh, now there’s a thought...

 

The use of XDBE is one of those things that is *probably* a good idea, and certainly seemed so at the time. But maybe is interacts badly with some systems?

 

Can you reconfigure your fltk library build, and disable XDBE (pass, I think, --disable-xdbe to configure when you invoke it) which will force fltk to use alternate double buffering strategies.

 

See if that behaves any differently.

 

Cheers,

--

Ian

 

 

From: fltkg...@googlegroups.com [mailto:fltkg...@googlegroups.com] On Behalf Of André Miranda
Sent: Wednesday, October 09, 2013 3:18 AM
To: fltkg...@googlegroups.com
Cc: erco_...@seriss.com
Subject: Re: [fltk.general] Fl_Double_Window Flickering while resizing

 

                    *** WARNING ***

This message has originated outside your organisation,
  either from an external partner or the Global Internet.
      Keep this in mind if you answer this message.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Greg Ercolano

unread,
Oct 9, 2013, 5:42:08 AM10/9/13
to fltkg...@googlegroups.com
On 10/09/13 01:32, MacArthur, Ian (Selex ES, UK) wrote:
> Oh, now there�s a thought...
>
> The use of XDBE is one of those things that is **probably** a good idea, and certainly seemed so at the time. But maybe is interacts badly with some systems?
>
> Can you reconfigure your fltk library build, and disable XDBE (pass, I think, --disable-xdbe to configure when you invoke it) which will force fltk to use alternate double buffering strategies.
>
> See if that behaves any differently.

Mmm, good idea!

I concur; rebuilding fltk with xdbe off, then rebuilding your app against
that new build might affect the problem.

André Miranda

unread,
Oct 10, 2013, 7:24:09 PM10/10/13
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I tried the following configs:
Graphics: X11+Xft+Xinerama
JPEG=System
PNG=System
ZLIB=System
Large Files: YES
OpenGL: YES
Threads: YES

Graphics: X11
JPEG=System
PNG=Builtin
ZLIB=Builtin
Large Files: YES
OpenGL: NO
Threads: YES

Graphics: X11
JPEG=System
PNG=Builtin
ZLIB=Builtin
CAIRO=lib
Large Files: YES
OpenGL: NO
Threads: YES

No difference...
FLTK version is 1.3.2 Release just downloaded a while ago.
I have also turned off the Xfwm Compositor.

Any more thought?
Thanks.

André Miranda

unread,
Oct 12, 2013, 5:54:15 PM10/12/13
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Two more things I discovered:
1. It only happens for PNG file which have alpha channel.
2. This problem occurred on LXDE(openbox).

I hope this info help us tracking down this problem.

Greg Ercolano

unread,
Oct 12, 2013, 9:53:34 PM10/12/13
to fltkg...@googlegroups.com
On 10/12/13 14:54, Andr� Miranda wrote:
> Two more things I discovered:
> 1. It only happens for PNG file which have alpha channel.

That's good to know, and will probably help narrow it down.

I noticed in Fl_Image.cxx we have an alpha_blend() function
that is enabled on non-apple/non-win32 systems (i.e. linux)

I'm assuming it's used in your case.

It seems to me there's an fl_read_image() in there which
is probably handling the on-screen alpha compositing.

fl_read_image() is an unusual function in that it has
to read pixels back from the hardware, and I could see
where this /might/ be messing around with the double
buffering stuff. Maybe.

Can I suggest a simple test:


Comment out the fl_read_image() function and replace it
with a printf() that prints a message.

Then rebuild fltk, then rebuild your app against the new
fltk build, and see if you can replicate the flicker problem.

You might want to zero out the dst buffer (that fl_read_image()
would normally fill out) so you don't get pixel noise.

Just a guess that this is the problem, but easy to rule out.


Greg Ercolano

unread,
Oct 12, 2013, 10:12:45 PM10/12/13
to fltkg...@googlegroups.com
On 10/12/13 18:53, Greg Ercolano wrote:
> On 10/12/13 14:54, Andr� Miranda wrote:
>> Two more things I discovered:
>> 1. It only happens for PNG file which have alpha channel.
>
> That's good to know, and will probably help narrow it down.


OK, I could replicate some weird flickers with an alpha image pair
on my linux box.

I took the code example and images from here:
http://seriss.com/people/erco/fltk/#AlphaBlend

..and changed the code so that it used an Fl_Double_Window,
and made the window resizable.

Definitely could replicate flicker and weird behaviors:

When sizing the window larger than the 0,0,256,256,
the non-image section of the window flickered a lot
from black-to-gray.

When sizing the window /smaller/ than the 0,0,256,256,
it seemed like the fl_read_pixels() function stopped working right,
causing it to seemingly composite the composites, causing the two
images to 'dissolve' into merge over each other 100% (instead of 50/50).

If I do the test I mentioned, commenting out the fl_read_pixels()
in FLTK's src/Fl_Image(), the flicker problem is greatly reduced.

If that affects your issue to, then perhaps focusing on what fl_read_pixels()
does would yield results towards a fix.

Might be time to open an STR, since we're starting to have enough
info for a fuller investigation.

Here's the modified example code I used (double window + resizable):

#include <stdio.h>
#include <string.h>
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Shared_Image.H>
#include <FL/Fl_PNG_Image.H>
#include <FL/fl_draw.H>
//
// Demonstrate overlapping alpha blended images -- erco 06/09/09
//
class MyWindow : public Fl_Double_Window {
Fl_PNG_Image *left;
Fl_PNG_Image *right;
void GetFLTKVersion(char *s) { // get fltk version info for demo -- optional
sprintf(s, "FLTK %d.%d.%d", FL_MAJOR_VERSION, FL_MINOR_VERSION, FL_PATCH_VERSION);
}
public:
void draw() {
Fl_Double_Window::draw(); // Draw window widget first
fl_font(FL_HELVETICA, 40); // set font
fl_color(FL_BLACK); // set color
fl_draw("This is a test", 10, 150); // draw a text string
left->draw(0,0); // draw left alpha image over the above
right->draw(0,0); // draw right alpha image over the above
}
MyWindow(int W, int H) : Fl_Double_Window(W,H) {
char s[80]; GetFLTKVersion(s); copy_label(s); // (show fltk version -- optional)
left = new Fl_PNG_Image("/tmp/left-alpha.png"); // assumes images in cwd
right = new Fl_PNG_Image("/tmp/right-alpha.png"); // assumes images in cwd
resizable(this);
show();
}
};
int main() {
fl_register_images();
MyWindow win(256,256);
win.end();
return(Fl::run());
}

André Miranda

unread,
Oct 12, 2013, 10:45:40 PM10/12/13
to fltkg...@googlegroups.com, erco_...@seriss.com
On Saturday, October 12, 2013 10:53:34 PM UTC-3, Greg Ercolano wrote:
                Comment out the fl_read_image() function and replace it
                with a printf() that prints a message.

        Then rebuild fltk, then rebuild your app against the new
        fltk build, and see if you can replicate the flicker problem.

humm, I did the modification you suggested and for my test case it has "cured" the flicker(even though the image background is drawn as black).
But your test case still flickers here.
Thank you!

André Miranda

unread,
Oct 29, 2013, 5:35:45 PM10/29/13
to fltkg...@googlegroups.com
Just for the record, this problem doesn't happen under Gnome nor KDE.
People at Xfce seems unresponsive about this problem.
Greg, any news about this issue?

Greg Ercolano

unread,
Oct 29, 2013, 5:54:20 PM10/29/13
to fltkg...@googlegroups.com
Nothing new, other than to open an STR that summarizes
the details and specifics found in this thread.


André Miranda

unread,
Oct 30, 2013, 12:40:44 AM10/30/13
to fltkg...@googlegroups.com, erco_...@seriss.com
Done: http://www.fltk.org/str.php?L3001
Thanks for your attention and patience :)

MacArthur, Ian (Selex ES, UK)

unread,
Oct 30, 2013, 5:17:43 AM10/30/13
to fltkg...@googlegroups.com
On 10/29/13 14:35, André Miranda wrote:
> Just for the record, this problem doesn't happen under Gnome nor KDE.
> People at Xfce seems unresponsive about this problem.
> Greg, any news about this issue?


Just out of interest (and as a potential workaround I guess) if you turn off the "show window contents while dragging / resizing" option in xfce (I'm not sure what they actually call that option, but ISTR they did have an option to do that...) does that then "hide" the problem?

Might be useful to know that, in case others are similarly afflicted I guess!

Cheers,
--
Ian

André Miranda

unread,
Oct 31, 2013, 6:51:18 PM10/31/13
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
On Wednesday, October 30, 2013 6:17:43 AM UTC-3, MacArthur, Ian (Selex ES, UK) wrote:
Just out of interest (and as a potential workaround I guess) if you turn off the "show window contents while dragging / resizing" option in xfce (I'm not sure what they actually call that option, but ISTR they did have an option to do that...) does that then "hide" the problem?

Might be useful to know that, in case others are similarly afflicted I guess!

Cheers,
--
Ian

This option in Xfce is located at Settings -> Window Manager -> Advanced -> Hide content of windows[When resizing].
Indeed it hides most of the flicker, but right after I release the mouse button and the window redraws itself, one can see a fast flicker.
Reply all
Reply to author
Forward
0 new messages