STR #3059: Fl_Window no longer drawing the scheme's bg, Fl::scheme_bg_

STR #3059

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Fl_Window no longer drawing the scheme's bg, Fl::scheme_bg_
Version:	1.3-current
Created By:	greg.ercolano
Assigned To:	AlbrechtS
Fix Version:	1.3.4 (SVN: v10607)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	greg.ercolano 15:29 Feb 26, 2014

This happened sometime since 1.1.10. Fl_Window::draw() used to call Fl_Group::draw() which drew the box, label, and children. In r6669 (AlbrechtS 02/25/2009) this logic was changed to only draw the box() and children, which skips the label drawing code, and thus seems to prevent the image() from being drawn, in this case the scheme's Fl::scheme_bg_ tile image. This is tricky business, as the handling of this ends up being a deep calling stack, and we have some idiosyncrasies with Fl_Windows that must be taken into account: The x()/y() values of an Fl_Window are relative to the root, not the window. This should be kept in mind when code tries to draw relative to the x()/y() of the widget. The window's label() text is not drawn, but rather set as the window manager title. So even though the label is not drawn, we have to remember the label also manages the image() for the widget, so though the window doesn't really have label() text we draw, we might still be drawing an image(), so we can't really disable /all/ label drawing code if an image is to be drawn, either with an image() or with a scheme background set with Fl::scheme_bg_. Tracked this down due to a recent question on fltk.general, subject: [fltk.general] FL_Window (Settings / Appearance) asking about the old plastic theme's "venetian blind" effect not showing up in 1.3.x. Some info about how the scheme background is drawn in an Fl_Window with the scheme set to "plastic": The scheme_bg_ is an Fl_Tiled_Image of an Fl_Pixmap in src/tile.xpm, and its width/height are set to the *root* window's size, so on a 1920x1200 screen, the Fl_Tiled_Image w()=1920 and h()=1200. When the window is drawn, the calling stack to draw the venetian blinds is fairly involved: > Fl_Window::draw(void) calls.. > Fl_Group::draw(void) which calls.. > Fl_Widget::draw_label(void) in fl_labeltype.cxx which calls.. > Fl_Widget::draw_label(X,Y,W,H) in fl_labeltype.cxx which calls.. > Fl_Widget::draw_label(X,Y,W,H,a) in fl_labeltype.cxx which calls.. > Fl_Label::draw(X,Y,W,H,a) in fl_labeltype.cxx which calls table[boxtype](this, X, Y, W, H, align).. > fl_normal_label(Fl_Label*,x,y,w,h,align) in fl_labeltype.cxx which calls.. > ::fl_draw(s, X, Y, W, H, align, image, 0) in fl_draw.cxx which calls.. > Fl_Tiled_Image::draw(X,Y,W,H,cx,cy) in Fl_Tiled_Image.cxx which in an x/y loop, /repeatedly/ calls.. > Fl_Image::draw(x,y) which calls > Fl_Pixmap::draw(x,y) in Fl_Pixmap.H which calls.. > Fl_Pixmap::draw(x,y,w,h,0,0) in Fl_Pixmap.cxx [where w() and h() are the root window's w/h!] which calls.. > fl_graphics_driver->draw(this,X,Y,W,H,clipx,clipy) in Fl_Pixmap.cxx which, depending on the platform (linux), calls.. > Fl_Xlib_Graphics_Driver::draw(Fl_Pixmap*,X,Y,W,H,cx,cy) in Fl_Pixmap.cxx which draws the 64x64 tile I should add, there's much unnecessary looping (I added some printfs) that draws the tiles far more times than needed to fill the window. This is probably because the window's w/h are lost at the point where ::fl_draw() calls Fl_Image::draw(x,y) without a w/h to constrain its lower and right dimension. Also, the X/Y values during the loop in Fl_Tiled_Image can end up starting with negative numbers, I think due the align logic in fl_draw() that tries to draw the image centered relative to its huge root window w/h values. Some sanity should probably be included here, so that the x/y loop starts and ends somewhere within the current window's w/h constraints, as there's no point in drawing at negative coordinates, or coordinates outside the w/h size of the window.

#2	ianmacarthur 03:25 Sep 05, 2014

I wonder if just removing the venetian blind effect is a better bet; it's pretty outdated now anyway!

#3	AlbrechtS 08:14 Feb 17, 2015

Fixed in Subversion repository. As Greg found out the problem was that the label was not drawn anymore, and since the label drawing code is also responsible for drawing the window's background image, the plastic scheme's "venetian blind" background was not drawn. However, this issue affects any background image, so it had to be restored. svn r 10584 fixes the label and background drawing. I did not do anything concerning the tiled image drawing, which (as Greg reported) might draw too much (outside the window bounds). I believe however that the new bg drawing (which is restricted to the window coordinates) may fix this "tiled image excessive drawing" as well, as far as the window background is concerned. I propose to close this STR as resolved unless anybody objects because of the Fl_Tiled_Image drawing issue. If so, I suggest to open another STR instead of keeping this one open.

#4	AlbrechtS 12:30 Mar 01, 2015

Note: the commit in svn r 10584 fixed the "Venetion blind" issue. However, the excessive drawing was still present, because the scheme setup used Fl::w() and Fl::h() when setting up the Fl_Tiled_Image in src/Fl_get_system_colors.cxx. This is fixed now as of svn r 10598. There are also optimizations to draw only those tiles of the background image that are not clipped in svn r 10598 as well.

#5	AlbrechtS 06:17 Mar 09, 2015

Unfortunately there was another regression showing the label text or artefacts in the window since svn r10598. This is fixed in r 10607. Summary of related svn commits: r10584: Fixes background image drawing (incomplete). r10598: Fixes excessive image drawing of clipped areas. r10607: Fixes label drawing artefacts. Fix version is now r10607.