| [ 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 ]
|
| |