summaryrefslogtreecommitdiffstats
path: root/chrome/common/x11_util.cc
Commit message (Collapse)AuthorAgeFilesLines
* Draw the normal window's frame in maximized mode. See BUG for more detail. ↵oshima@chromium.org2009-11-301-0/+16
| | | | | | | | | | | Dan will investigate further when he has time. BUG=28580, 727 (chromeos) TEST=None Review URL: http://codereview.chromium.org/436039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33302 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Make InfoBubble use an override-redirect (popup) window.derat@chromium.org2009-09-301-0/+29
| | | | | | | | | | | | | This makes it work correctly in ion3 and other window managers that don't expect clients to try to move top-level windows themselves. This implementation grabs the pointer and keyboard. By doing this and using an override-redirect window, we should be able to avoid worrying about interactions with different window managers. The only downside (alluded to in the previous code) is that window manager keybindings don't make it through until the user dismisses the bubble by clicking outside of it or hitting Enter or Escape. I don't think this will be a problem; it's no different from what happens when you open a context menu in an app. BUG=20523 TEST=tested first-run and bookmark bubbles in Metacity, ion3, Fluxbox, KDE4, and the WM that I'm working on Review URL: http://codereview.chromium.org/198016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27578 0039d316-1c4b-4281-b951-d872f2087c98
* Adds NOTREACHED if we ever hit the max cache size of the render pictsky@chromium.org2009-09-211-1/+10
| | | | | | | | | | | | format cache. BUG=none TEST=none TBR=estade Review URL: http://codereview.chromium.org/217002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26689 0039d316-1c4b-4281-b951-d872f2087c98
* Changes x11_util::GetRenderVisualFormat to keep a cache of rendersky@chromium.org2009-09-181-5/+49
| | | | | | | | | | | | picts. This way we can support different visuals while still caching the value. BUG=none TEST=none Review URL: http://codereview.chromium.org/210021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26615 0039d316-1c4b-4281-b951-d872f2087c98
* gtk: Implement and use x11_util::GetXWindowStack, which is a less flaky and ↵jhawkins@chromium.org2009-09-011-6/+45
| | | | | | | | | | faster version of gdk_screen_get_window_stack. The latter was not consistently returning our browser windows in the window stack. BUG=none TEST=Extensive tab dragging. Review URL: http://codereview.chromium.org/179056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25112 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Fix Valgrind error in VisitedLinkEventsTest.Coalescense.derat@chromium.org2009-08-011-0/+4
| | | | | | | | | | | | | | I introduced the error in r22193; it shows up when there's no X server to connect to. I get a "GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed" message with this change, but I'm not sure if it's from my code or if it was already there, and the tests still pass. TEST=ran VisitedLinkEventsTest.Coalescense under Valgrind with DISPLAY=:6 Review URL: http://codereview.chromium.org/159753 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22240 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Autodetect whether the custom frame should be used.derat@chromium.org2009-07-311-0/+69
| | | | | | | | | | | | | | | | | | | | | | | Listing a bunch of strings from WMs' source sucks, but I can't think of any way to detect tiling WMs that don't support the EWMH (see the bug and the comment in this CL), so this seems safer. Tested with the following: - wiped out related prefs and started chrome under ion3; custom frame not used - quit and started under metacity; custom frame *was* used - toggled custom frame pref off and restarted under metacity again; custom frame not used - toggled it back on and restarted under ion3; custom frame was used BUG=15861 TEST=see above Review URL: http://codereview.chromium.org/160374 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22193 0039d316-1c4b-4281-b951-d872f2087c98
* Two tab dragging fixes for various window managers:jhawkins@chromium.org2009-06-251-11/+48
| | | | | | | | | | | * Reverse the order of enumeration when enumerating all top-level windows. XQueryTree returns the list of windows in bottom-to-top order, while DockInfo expects the windows in top-to-bottom order (ratpoison WM, Awesome WM). * Extend the enumeration one level deeper for window managers that parent top-level windows into an unnamed real top-level window (ion WM). BUG=14004 TEST=Extensive tab dragging in the following WMs: Metacity, Compiz, kwm, ion3, xmonad, ratpoison, awesome. Review URL: http://codereview.chromium.org/149028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19303 0039d316-1c4b-4281-b951-d872f2087c98
* Revert to enumerating all X windows if the Window Manager doesn't support ↵jhawkins@chromium.org2009-06-221-0/+19
| | | | | | | | | | _NET_CLIENT_LIST_STACKING. BUG=14004 TEST=Drag tabs in and out of tabstrip in xmonad window manager. Review URL: http://codereview.chromium.org/141061 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18949 0039d316-1c4b-4281-b951-d872f2087c98
* Use the convenience function gdk_screen_get_window_stack to enumerate ↵jhawkins@chromium.org2009-06-101-19/+5
| | | | | | | | | | top-level gdk windows instead of querying Xlib directly, which doesn't work across many window managers. BUG=none TEST=Exhaustive tab dragging in multiple window managers (Compiz, Metacity, KWM). Review URL: http://codereview.chromium.org/119345 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18098 0039d316-1c4b-4281-b951-d872f2087c98
* Implement dragging a tab back into a tabstrip for gtk.jhawkins@chromium.org2009-06-031-2/+40
| | | | | | | | BUG=none TEST=Open a browser window with two tabs. Drag one of those tabs in and out of the window's tabstrip many times. Open a new window and drag a tab into that window's tabstrip. Review URL: http://codereview.chromium.org/118142 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17542 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: use opaque NativeViewIdsagl@chromium.org2009-04-241-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently we are still passing GtkWidget* into the renderer and trusting the value on the way out. With this patch we switch to using opaque values. These opaque values are handled by a GtkNativeViewIdManger, a singleton object which maintains the list of currently valid ids and their current X window ids. We don't pass the X window ids directly to the renderer because they are a) guessable and b) possibly variable for a GtkWidget. From a patch size point of view, the X window isn't current created at the point where we need it so significant work would be needed to reorder operations to fix that as well. This patch also removes the GTK accesses from the BACKGROUND_X11 thread which were a temporary hack. http://codereview.chromium.org/92110 BUG=9014,9869,10787 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14405 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: move X operations from the IO to UI2 thread.agl@chromium.org2009-04-221-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (r14075 take two) Currently we perform several X operations on the IO thread including geometry and clipboard work. This is causing races inside Xlib and crashing the browser. These are the result of synchronous calls from the renderer, so we cannot route these requests to the UI thread without risking deadlock. Thus we introduce the UI2 thread. This thread has a second connection to the X server and can perform X operations safely the without UI thread. Work remains to be done: Since we still have the hack where we pass GtkWidget pointers into the renderer and back, we still have to access these structures from the IO and UI2 threads. This still needs to be fixed, but this is not the patch for it. Also, not all the X calls from the IO thread have been moved over in this patch; just a few small ones. http://codereview.chromium.org/67145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14206 0039d316-1c4b-4281-b951-d872f2087c98
* I managed to break test_shell. Reverting. I'll fix tomorrow.agl@chromium.org2009-04-211-30/+0
| | | | | | | Reverts r14075 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14080 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: move X operations from the IO to UI2 thread.agl@chromium.org2009-04-211-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we perform several X operations on the IO thread including geometry and clipboard work. This is causing races inside Xlib and crashing the browser. These are the result of synchronous calls from the renderer, so we cannot route these requests to the UI thread without risking deadlock. Thus we introduce the UI2 thread. This thread has a second connection to the X server and can perform X operations safely the without UI thread. Work remains to be done: Since we still have the hack where we pass GtkWidget pointers into the renderer and back, we still have to access these structures from the IO and UI2 threads. This still needs to be fixed, but this is not the patch for it. Also, not all the X calls from the IO thread have been moved over in this patch; just a few small ones. http://codereview.chromium.org/67145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14075 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: support displays without Xrender support.agl@chromium.org2009-02-261-3/+35
| | | | | | | | | | | VNC servers don't support Xrender. For this use case, we implement a slow fallback which byte-fiddles the Skia bitmaps as needed to support 32 and 24 bit visuals. Review URL: http://codereview.chromium.org/27227 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10523 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: fix XRENDER support for NXagl@chromium.org2009-02-261-2/+7
| | | | | | | | | | | | | | | The NX X server doesn't support xRGB32 XRENDER picture formats. So, if we don't find one of those formats, fall back on ARGB32, which is fine, except that the X server will spend time dealing with an alpha channel which is all 254 or 255. ARGB32 support is required by the XRENDER spec. (This doesn't fix VNC, a patch for that is forthcoming.) Review URL: http://codereview.chromium.org/28192 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10484 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: fix GDK error when switching tab contentsagl@chromium.org2009-02-261-0/+4
| | | | | | | | | | | | | | When we remove a drawing area from a container, GTK destroys the X window. However, the BackingStore remembers the old X window id and emits X requests using the wrong id. This change makes the window id an argument to ShowRect and makes the pixmaps from the root window instead. Review: http://codereview.chromium.org/27169 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10439 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: switch red and blue channelsagl@chromium.org2009-02-251-2/+2
| | | | | | | Review URL: http://codereview.chromium.org/28135 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10378 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: server side backing storesagl@chromium.org2009-02-251-0/+181
This converts Linux to using server-side backing stores. Rather than keeping a backing store in heap memory in the browser, we create a pixmap in the X server. This means that expose messages don't require us to transport any images to the X server, we can just direct it to paint from the pixmap. Also, scrolling can be performed server side also. This greatly improves performance over remote X. Also, shared memory transport to the X server is implemented. Shared memory segments can be created in the renderer and mapped directly into the X server. Review URL: http://codereview.chromium.org/27147 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10369 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-02 03:45:57 +0000