summaryrefslogtreecommitdiff
path: root/gdk/gdk.c
Commit message (Collapse)AuthorAgeFilesLines
* Trivial formatting fixMatthias Clasen2016-03-111-21/+21
|
* Control legacy GL context via environment variableEmmanuele Bassi2015-10-071-0/+1
| | | | | | | For testing purposes, we may want to force the creation of legacy GL contexts via an environment variable. https://bugzilla.gnome.org/show_bug.cgi?id=756142
* Allow overriding WM_CLASS from the command lineLars Uebernickel2015-05-101-0/+8
| | | | | | | | | Even when the program itself calls gdk_set_program_class(). There's currently no way for this function to be called without breaking gdk's --class command line option, because you cannot call it before gtk_init(). https://bugzilla.gnome.org/show_bug.cgi?id=747634
* Make global GDK libgtk_only functions more privateEmmanuele Bassi2014-11-081-8/+54
| | | | | | | | | | | | | | | The current way of exposing GDK API that should be considered internal to GTK+ is to append a 'libgtk_only' suffix to the function name; this is not really safe. GLib has been using a slightly different approach: a private table of function pointers, and a macro that allows accessing the desired symbol inside that vtable. We can copy the approach, and deprecate the 'libgtk_only' symbols in lieu of outright removal. https://bugzilla.gnome.org/show_bug.cgi?id=739781
* Export API to set GL flagsMatthias Clasen2014-11-061-6/+6
| | | | This will be used in the inspector.
* Add support for GDK_GL=texture-rectanglesAlexander Larsson2014-11-061-0/+1
| | | | This allows us to test our support for GL_ARB_texture_rectangle
* Add GDK_GL env var and GdkGLFlagsAlexander Larsson2014-11-061-1/+15
| | | | | | | | | | | | | | | | | | | | | This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always. It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG is really only about debug loggin. It also adds some completely new flags: software-draw-gl: Always use software fallback for drawing gl content to a cairo_t. This disables the fastpaths that exist for drawing directly to a window and instead reads back the pixels into a cairo image surface. software-draw-surface: Always use software fallback for drawing cairo surfaces onto a gl-using window. This disables e.g. texture-from-pixmap on X11. software-draw: Enables both the above.
* gdk: Add GDK_DEBUG=noglBenjamin Otte2014-10-161-0/+1
| | | | | | | This is mostly useful for fallback testing. I suppose if people want finer grained GL ability testing, they can use Mesa environment variables to tune things.
* gdk: Add support for OpenGLAlexander Larsson2014-10-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
* threads: Do not release the GDK lock if it hasn't been acquired yetEmmanuele Bassi2014-08-261-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since GLib ≥ 2.41, attempting to release an unlocked mutex will abort(), as it happens on most systems already. Given the lack of proper documentation on how to use GDK with threads, there is code in the wild that does: gdk_threads_init (); gdk_init (); ... gtk_main (); instead of the idiomatically correct: gdk_threads_init (); gdk_threads_enter (); gtk_init (); ... gtk_main (); ... gdk_threads_leave (); Which means that gtk_main() will try to release the GDK lock, and thus trigger an error from GLib. we cannot really fix all the wrong code everywhere, and since it does not cost us anything, we can work around the issue inside GDK itself, by trying to acquire the GDK lock inside gdk_threads_leave() with trylock(). https://bugzilla.gnome.org/show_bug.cgi?id=735428
* gdk: add many missing (nullable) return value annotationsEvan Nemerson2014-05-111-4/+5
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=729834
* Drop unneeded deprecation suppressionMatthias Clasen2014-05-021-2/+0
| | | | Removing this did not produce any deprecation warnings.
* docs: use Returns: consistentlyWilliam Jon McCann2014-02-191-7/+7
| | | | Instead of Return value:
* Docs: use // for comments in examplesMatthias Clasen2014-02-141-5/+5
| | | | | Without sgml mode, we can't escape /* as /* anymore, so just switch to // for comments in examples.
* gdkthreads: Update documentationJasper St. Pierre2014-02-071-203/+29
|
* docs: use proper quotations instead of '*'William Jon McCann2014-02-071-1/+1
|
* docs: use apostrophes in *n'tWilliam Jon McCann2014-02-071-6/+6
|
* Use proper quotes in gdkWilliam Jon McCann2014-02-051-1/+1
|
* docs: use ` instead of <literal>William Jon McCann2014-02-041-2/+2
|
* docs: don't use <option>William Jon McCann2014-02-041-2/+2
|
* docs: use markdown for <envar> tagsWilliam Jon McCann2014-02-041-1/+1
|
* docs: Identify examples that are C codeWilliam Jon McCann2014-01-291-4/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=723119
* docs: use |[ ]| instead of <programlisting></programlisting>William Jon McCann2014-01-291-8/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=723119
* docs: don't use <emphasis>William Jon McCann2014-01-281-1/+1
| | | | It is a little heavy handed. The text can speak for itself.
* docs: add missing docs for GDK_WINDOWING_WAYLANDWilliam Jon McCann2014-01-201-0/+9
|
* docs/comments: Fix spelling of 'explicitly'Volker Sobek2014-01-181-2/+2
| | | | | | | This replaces all occurrences of 'explicitely' with 'explicitly'. Only code comments and gtk-doc statements are affected. https://bugzilla.gnome.org/show_bug.cgi?id=722429
* Fix GI warningsJasper St. Pierre2013-10-091-7/+4
|
* Add GDK_AVAILABLE_IN_ALL annotations in gdkMatthias Clasen2013-05-051-0/+1
| | | | | This is in preparation to modernizing our handing of exported symbols.
* Bug 606378 - gdk doesn't handle non-main thread rendering on QuartzJohn Ralls2013-05-031-5/+5
| | | | Document that the restrictions on Win32 apply also to Quartz.
* gdk: Remove new gdk_display_manager_peek() APIBenjamin Otte2013-05-021-3/+0
| | | | | | It's not necessary anymore because gdk_display_manager_get() always succeeds and the value is independant of when it was called as it's no longer backend specific.
* Deprecate gdk_get_display()Benjamin Otte2013-04-011-0/+3
|
* gdk: Shuffle code aroundBenjamin Otte2013-04-011-0/+15
| | | | Make implementation, header and documentation be at the correct place.
* Make gdk_display_open_default_libgtk_only more robustMatthias Clasen2013-03-231-1/+4
| | | | | | Make this function return NULL if GDK could not be initialized. We check this by seeing if there is a display manager singleton.
* gdk: Implement GInitable on GdkDisplayManagerThomas Wood2013-03-221-3/+0
| | | | | | | | | | | | | | | Add GInitable interface with a default implementation that always succeeds. This allows backends to override the GInitable implementation and add their own checks to determine if the backend can be loaded. If a backend cannot be loaded, GDK can attempt to load the next available backend. Since backends may need to read any relevant options (such as the display flag) to determine if they can be created successfully, this patch also removes calls that attempt to create the display manager before the options have been parsed. https://bugzilla.gnome.org/show_bug.cgi?id=694465
* gdk: Add a debug category for settingsBenjamin Otte2013-02-191-1/+2
|
* Add GDK_DEBUG=framesOwen W. Taylor2013-02-141-1/+2
| | | | | | Add a debug option to print out detailed statistics about each frame drawn. https://bugzilla.gnome.org/show_bug.cgi?id=685460
* Bump GLib dependency to 2.35Matthias Clasen2012-11-041-2/+0
| | | | And drop deprecated g_type_init() calls.
* Expand the thread deprecation documentationMatthias Clasen2012-08-011-1/+3
| | | | | | | The story is slightly different for applications vs libraries; make it clear that libraries should continue using the lock so we don't break applications that haven't been ported to the 'single thread' model yet.
* Improve threading documentationMatthias Clasen2012-07-301-4/+13
| | | | | | This commit just adds a small section to the threading documentation about the deprecation. More is needed here, including a migration example.
* gdk: Deprecate thread functionsMatthias Clasen2012-07-301-0/+12
| | | | | | | | | | | | This commit deprecates gdk_threads_init, gdk_threads_enter, gdk_threads_leave and gdk_threads_set_lock_functions. Using GTK+ from multiple threads does not work at all on Windows, and is problematic on other platforms as well. We want to move to a world where all GTK+ calls are made from the main thread. Use g_main_context_invoke, g_idle_add and related functions if you need to schedule GTK+ calls from other threads. http://bugzilla.gnome.org/show_bug.cgi?id=680754
* gdk: Don't use GDK_THREADS_ENTER/LEAVE macros internallyMatthias Clasen2012-07-301-2/+4
| | | | | | These are just wrappers for the functions, and we want to deprecate them. Stopping to use them internally is a good first step.
* Change FSF AddressJavier Jardón2012-02-271-3/+1
|
* Add some documentation around deprecationsMatthias Clasen2012-02-271-1/+21
|
* Use G_SOURCE_CONTINUE/REMOVEMatthias Clasen2012-01-301-1/+1
| | | | | Now that GLib provides these macros, we should use them to make the code more readable.
* Drop references to g_thread_init()Matthias Clasen2011-11-091-14/+11
| | | | | We are already requiring GLib 2.31, so g_thread_init() is never needed anymore.
* GDK: Adapt to GLib thread api changesMatthias Clasen2011-11-011-9/+3
|
* gdk: Use const instead G_CONST_RETURNJavier Jardón2011-06-101-2/+2
|
* gdk: Add GDK_RENDERING environment variableBenjamin Otte2011-03-111-0/+13
| | | | | | | It's useful for debugging rendering issues, both correctness and performance wise. See the added documentation for what it does and how it works.
* Remove support for GDK_NATIVE_WINDOWSAlexander Larsson2011-03-081-2/+2
| | | | | | | | | | GDK_NATIVE_WINDOWS was a way to keep some old apps running that did weird things in gtk2. We should not have to carry this forwards in gtk 3.x. We do however keep a g_warning() call reminding people of this fact to ease debugging when they try to port their applications. https://bugzilla.gnome.org/show_bug.cgi?id=644119
* Give the GDK docs some loveMatthias Clasen2011-02-091-21/+5
| | | | | Reorganize some sections, drop the largely redundant multihead section, add some more information about multiple backends.
View Lorry Controller Status