| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3142
| 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: | WIN32 |
|---|
| Summary: | fl_read_image() ignores OpenGL data under MSWindows and Mac OS |
|---|
| Version: | 1.3.3 |
|---|
| Created By: | manolo |
|---|
| Assigned To: | manolo |
|---|
| Fix Version: | 1.3-current (SVN: v10436) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | manolo
07:24 Oct 23, 2014 |
| The fl_read_image() function allows to read the content of a rectangle
of the current window. When an Fl_Gl_Window is involved,
fl_read_image() returns the GL pixel data correctly under MSWindows,
but ignores them altogether under X11 and Mac OS.
See attached window capture under MSWindows XP (WindowsXP.pdf)
and under X11 (debian.ps). Both captures were done under VirtualBox
on a macintosh computer. | |
| |
| #2 | manolo
07:43 Oct 23, 2014 |
| The attached window captures have been produced with the print menu of
the test/cube demo modified as follows:
replace line 163 of test/cube.cxx
printer.print_widget( win );
by
printer.print_window_part( win, 0, 0, win->w(), win->h() );
This change makes the print command call fl_read_window(). | |
| |
| #3 | AlbrechtS
07:57 Oct 23, 2014 |
| This is strange - I found the opposite behavior on Windows and Linux. See files cube_linux_mod.pdf and cube_win_mod.pdf.
My Windows ignores GL data, whereas Linux shows GL data. Both tests have been done with the modifications posted above by Manolo.
Windows 8.1, MinGW, gcc 4.8.1
Linux Ubuntu 14.04, gcc 4.8.2
Under Linux I used ps2pdf to convert the large ps file to pdf. | |
| |
| #4 | manolo
12:35 Oct 23, 2014 |
| - With Windows7 hosted by VirtualBox on macintosh, same as above:
the GL panels are correctly captured.
- With Windows7 and the very same exe used in VirtualBox,
but on a real Windows-running computer, same as reported by Albrecht:
the GL panels are ignored.
So there's a difference between VirtualBox and a true computer
for this application. Or does it depend on the graphics card?
There is another strange difference with X11. Albrecht has correctly
captured GL panels. I tested two situations, both for Linux Debian,
under VirtualBox, and with the X11 client on a Linux box and the server
on a macintosh. In both cases, the GL panels aren't captured
by fl_read_window().
Anyway, fl_read_image() produces different results on different
platforms in the presence of Fl_Gl_Windows.
It's possible, using the GL pixel capture technique used by the
Fl_Paged_Device::print_widget() function to reliably capture GL panels
in a cross-platform way. | |
| |
| #5 | AlbrechtS
12:49 Oct 23, 2014 |
| Note about X11: I tested with the X client and server both "in" the Virtualbox VM, i.e. a local display, and this worked well.
When I started the same application with a remote X display (on the VM's Win 8.1 host with a Cygwin X server), I got 4 identical messages:
Insufficient GL support
Insufficient GL support
Insufficient GL support
Insufficient GL support
and I did not at all see the GL output on the X display. That's certainly an X server problem, but maybe a hint that there could be more about different configurations. | |
| |
| #6 | manolo
23:46 Oct 23, 2014 |
| At this point, we both tried the X11 version of the modified cube demo
via VirtualBox: you with a Windows8 host and Linux Ubuntu guest,
I with a macintosh host and Linux Debian guest,
and obtained opposite results: no GL pixel capture for me,
correct GL pixel capture for you.
I'll try to find a true Linux box and see what happens. | |
| |
| #7 | manolo
04:18 Oct 24, 2014 |
| Attached cube_Debian_NoVBox.pdf obtained running the modified cube demo
on a Linux Debian (3.16.3 - gcc 4.7.3) without virtualization nor remote
display: GL pixels aren't captured.
Overall, it seems that when native (as opposed to virtualized) OS
are used, neither MSWindows, nor Linux, nor Mac OS can capture GL pixels
with the fl_read_image() function.
This function isn't entirely platform-independent as our experiments
with virtualized OSes show.
I would like to at least correct that for the
Fl_Paged_Device::print_window_part() function that currently calls
fl_read_image() and therefore misses GL pixels, because that is not
coherent with Fl_paged_Device::print_widget() that does capture GL data.
For fl_read_image() itself, should we leave it unchanged or
have it capture GL pixels that may occur in the targetted rectangle? | |
| |
| #8 | manolo
04:43 Oct 24, 2014 |
| Corrigendum: fl_read_image() does indeed capture GL pixels on a
Linux box (see attached cube_Debian_NoVBox2.pdf).
[file cube_Debian_NoVBox.pdf really has its GL panels covered by a
file save dialog, that is another issue].
So we do have platform-dependent fl_read_image() behaviour
for Fl_Gl_Windows:
- GL pixels are captured under Linux+X11 (and MSwindows hosted
by VirtualBox on a macintosh)
- GL pixels are ignored under MSWindows and Mac OS X
In addition, virtualized Linux+X11 captures GL pixels when the host
runs MSWindows but not when it runs Mac OS X, and Linux+X11 remotely
displayed using Mac OS X's X server (XQuartz) also fails to
capture GL pixels. | |
| |
| #9 | manolo
09:01 Nov 06, 2014 |
| Fixed in Subversion repository.
With the fix, fl_read_image() is consistent across platforms
and across OS virtualization software (tested with VirtualBox
on Mac OS host): whatever OpenGL data is present in the given rectangle
is captured and returned.
Non-GL subwindows of GL windows are also captured. | |
| |
| #10 | manolo
01:46 Jan 09, 2015 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
