| | [ Return to Bugs & Features | SVN ⇄ GIT ]
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: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #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. | |
[ Return to Bugs & Features ]
|
| |
