STR #1716

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features ]

STR #1716

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:3 - Moderate, e.g. unable to compile the software
Scope:2 - Specific to an operating system
Subsystem:X11
Summary:Bad background blending for rgba images
Version:1.2-current
Created By:sanel.z
Assigned To:mike
Fix Version:1.1.8 final (SVN: v6046)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size top right image
 
#1 wavexx
19:06 Feb 23, 2008
blending.patch.txt
2k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#1 sanel.z
04:22 Jun 25, 2007
Here is full description with solution:
 - when widget with rgba image (blended against it's background) is moved outside parent bounds, but partialy visible, X11 will yield "X_GetImage: BadMatch (invalid parameter attributes) 0x0", and background will be filled with garbage.

This is since XGetImage requires that specified drawable rectangle be fully visible on the screen and wholly contained within the outside edges of the window.

Solution will be (fl_read_image.cxx):
 if (!image) {
    if(X < 0) X = Fl::x();            // added
    if(Y < 0) Y = Fl::y();            // added
    if(X+w > Fl::w()) X = Fl::w()-w;  // added, alternatives ?
    if(Y+h > Fl::h()) Y = Fl::h()-h;  // added, alternatives ?

    image = XGetImage(fl_display, fl_window, X, Y, w, h, AllPlanes, ZPixmap);
 }
 
 
#2 ianmacarthur
04:44 Jul 13, 2007
What happens on multi-head systems or xinerama etc... Is this mod still correct then - I don't know how this all works...!  
 
#3 sanel.z
05:22 Jul 13, 2007
Actually this is very very ugly hack. Simply said, XGetImage require that fl_window drawable _must_ be fully visible.

In xinerama case, Fl::x/y/w/h will consult window manager for screen bounds, and is up to wm to report them correctly. On other hand, maybe using screen_xywh() will be better since it will directly consult xinerama (if present) for bounds.

Better alternative would be to pick up those bounds, draw image on visible area and quickly clip it with area size that is outside, using system specific calls.

This issue repeats in cases when you, for example, have window with moving boxes (with icons) in it; moving that box (when window is shown) in eg. x= -3, y= -3, where icon is partially visible, will yield given description.
 
 
#4 timothy.lee
21:21 Sep 16, 2007
Would the code posted in http://www.rdesktop.org/archive/2000/msg00077.html be sufficient to this problem?  
 
#5 mike
08:03 Nov 20, 2007
Just adjusting the rectangle won't do it, as the captured image will be wrong.

The extra pixmap method from the rdesktop.org link won't be fast enough.
 
 
#6 mike
08:06 Nov 20, 2007
Just adjusting the rectangle won't do it, as the captured image will be wrong.

The extra pixmap method from the rdesktop.org link won't be fast enough.
 
 
#7 wavexx
08:31 Feb 23, 2008
Does XGetSubImage has the same limitation if we specify the visible region only as proposed here?  
 
#8 wavexx
19:05 Feb 23, 2008
Ok, here's my first shot at fixing this:

I used XGetSubImage, which allows to reduce the query rectangle to visible bounds, removing the problem. XGetSubImage is only used when needed however.

I used screen_xywh to properly fetch the screen bounds, but I don't have any access to multi-screen X11 boxes. I assume that at least Xinerama should work, but PLEASE test. I don't know how XGetSubImage actually reacts to negative coordinates.

Sadly I don't know any better way to calculate bytes_per_lines and bitmap_pad for XCreateImage here. It seems that I need to pad to word boundaries, and I can't change arbitrarily the row alignment (so to save a column). This seems to be a constraint for XGetSubImage to have the _exact_ same format as the one returned for XGetImage. The _correct_ way to do that would be running a empty call to XGetImage, but, honestly, that sucks hard. I do not see any easy way to query the drawable to fetch this data, but maybe any of you has some more clue.

It occurred to me that XShmGetImage may be used here. I don't know if it suffers from the same problem as XGetImage (almost no documentation), but it's certainly worth a performance improvement. Since both flavors need to be supported anyway (XSHM or not), I *think* this only fits for 1.2 or beyond. Please raise an RFE for 1.2 when closing.
 
 
#9 matt
07:09 Feb 25, 2008
I decided to apply the patch. It will not solve each and every issue with transparentcy, but seems to work well on single-screen machines. Since this will go into RC1, I trust that we will hear about malfunctions pretty quickly ;-)

Thanks!!!
 
 
#10 pdewacht
15:02 Mar 02, 2008
Is a week pretty quickly? :)

The patch contains the following code:
+    XTranslateCoordinates(fl_display, fl_window,
+ RootWindow(fl_display, fl_screen), X, Y, &dx, &dy, &child_win);

But if you're drawing to a Fl_Double_Window, fl_displays contains an X Pixmap, not a Window. XTranslateCoordinates only works for windows, so that function fails, leaving dx and dy undefined, and fl_read_image ends up returning garbage.
 
 
#11 wavexx
14:05 Mar 03, 2008
I remember subscribing to the bug, but I never got any email.. I didn't
see it before. Sorry.

The user already described the problem quite well.
The solution is simple too, simply skip XTranslateCoords for pixmaps
(since these are always relative to the current screen).

The problem is how one can differentiate between Pixmap or Window IDs?
Checking the return of XTranslateCoordinates works fine, but still
generates a warning....
 
 
#12 matt
13:22 Apr 22, 2008
Fixed in Subversion repository.  
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.