After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 130547 - generic framebuffer support for gtk
generic framebuffer support for gtk
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
2.3.x
Other Linux
: Normal enhancement
: Big feature
Assigned To: gtk-bugs
gtk-bugs
Obsolete patch
Depends on:
Blocks:
 
 
Reported: 2004-01-05 07:47 UTC by Vladimir Vukicevic
Modified: 2011-06-06 23:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtk+ gl patch, against 2.3.1 (145.02 KB, application/octet-stream)
2004-01-05 07:49 UTC, Vladimir Vukicevic
  Details
generic framebuffer patch, take 2 (against gtk 2.4.0) (68.44 KB, patch)
2004-04-03 06:18 UTC, Vladimir Vukicevic
none Details | Review

Description Vladimir Vukicevic 2004-01-05 07:47:42 UTC
(opening bugzilla RFE per yosh's suggestion)

I've got a patch that extends the linux-fb gdk backend to handle rendering
to a generic buffer (32-bit RGBA buffer).  "extends" is used loosely here,
because the majority of the worked involved ripping out linuxfb
handling/setup, ripping out mouse drivers and keyboard input drivers, and
hardcoding a 32bpp truecolor visual.

I have the code pulled out in a separate "gl" subdirectory of gdk; mostly
copies of linux-fb, with some heavy changes in keyboard/mouse input
handling.  Keyboard and mouse input comes in via a GQueue protected by a
GMutex, which is polled via a GSource in the main loop.. keyboard input
uses SDL keysyms, for simplicity (thus there's a build-time dependency on a
SDL include file atm).

What this gives me is the ability to use gtk as a UI on top of an OpenGL
scene (or, presumably, Direct3D or just about anything where I can render
an image to the screen).  There are very few UI packages that can do this;
the ones that are out there generally suck.  There are no polished
middleware packages for this.

I'll attach a patch against 2.3.1, but it duplicates a lot of linux-fb
code.  Any suggestions on merging the two, or any feedback on the chances
of this type of gdk support making it into mainline gtk would be
appreciated. :)
Comment 1 Vladimir Vukicevic 2004-01-05 07:49:00 UTC
Created attachment 22926 [details]
gtk+ gl patch, against 2.3.1
Comment 2 Owen Taylor 2004-01-05 14:27:01 UTC
I'd say zero chance unless you can factor out the duplication
between that code and the linux-fb code.

As for how to factor out the duplication, I'm not sure
I can give specific advice without looking a lot at the
details but presumambly, there would be a 

 gdk/framebuffer

directory with the "draw to a framebuffer code", then 
linux-fb and whatever else that use the code from that.
Comment 3 Vladimir Vukicevic 2004-04-03 06:17:19 UTC
Okay, new patch.  No duplication; all the relevant code is merged in with
linux-fb, and is enabled when the gl gdk target is built.  The patched gtk
builds on both linux and win32, in both the native (x11/win32) and gdkgl modes,
as well as the old linux-fb backend on the linux side.  The patch is against 2.4.0.

Any feedback would be much appreciated.
Comment 4 Vladimir Vukicevic 2004-04-03 06:18:04 UTC
Created attachment 26278 [details] [review]
generic framebuffer patch, take 2 (against gtk 2.4.0)
Comment 5 Behdad Esfahbod 2006-04-06 18:47:02 UTC
Isn't this fixed already?  We both have support for rendering to pixmaps and a directfb backend now.  Not sure client-side buffers.
Comment 6 Kjartan Maraas 2006-12-26 14:22:49 UTC
Is the patch or parts of it still relevant?
Comment 7 makuchaku (Mayank) 2007-03-27 14:45:43 UTC
Many hunks from patch in comment 4 fail.
Comment 8 Matthias Clasen 2011-06-06 23:55:13 UTC
This is obviously obsoleted by the years; gdk has been more or less rewritten, several backends have come and gone...