Re: Question about pixman,x11perf and xserver
On 2011-12-05 06:39, 杨帅 wrote: 1.I recompile the pixman with enable-neon,but when I use the x11perf for testing ,I can‘t see the significant difference between the pixman with neon and pixman without neon.That's why? x11perf is an older test suite, and mostly only tests core graphics. Only x11perf -compwinwin and -comppixwin will make heavy use of pixman (along with the new-style text tests, a*text, aa*text and rgb*text to some extent). The good news is, most modern applications draw using those requests. 2.xserver use which drawing library to resizing the window,scroll the text window ,and so on? Depends on the application. Either pixman, or the fb directory of the server. 3.which library excepts pixman could I optimize using neon to improve the performance of xserver? xserver/fb But first, make sure you're working on something that matters to your application. In particular, cairo-perf-trace is probably more relevant these days than x11perf. See http://cgit.freedesktop.org/cairo-traces/tree/README Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xpenguins cont'd - repainting a window after penguins walk on it, and when penguins overlap.
On 2011-06-06 02:32, Amy C wrote: Can anyone think of a nice way to handle this? Create one window per penguin, using the SHAPE extension. The server will handle this (and most of the rest of the things you mention above) so you don't have to. A related question -- do you think it's viable to make one (transparent) window per penguin? It would be easier than drawing them directly onto an existing window (Famous Last Words), but say I had 25 penguins -- would 25 new windows be a big memory drain or is X good at that sort of thing? 25 windows is not many at all. The real cost is in exposing the underlying windows, but you're already doing that. (Thanks for that suggestion Xavier. I would rather not assume a compositor though, I have Fedora at work and Ubuntu at home but it's too sucky to have Compiz on it). SHAPE has been a standard extension for as long as I can remember. It should be available everywhere, and does not need a compositor. (The down side vs translucency+compiz is you can only have sharp edges with SHAPE; no alpha blending) Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xlib and rotated text?
On 2011-03-17 13:52, Chris wrote: I've had a look at freetype, but it seems like overkill for what I need and also a dependency I'm not sure I can afford (and it seems that then I also need fontconfig). So this is a last resort for me. You want to use ciaro/pango/fontconfig/freetype for this, rather than re-inventing the wheel. So, can I do it in Xlib without writing the complete matric algebra by myself (if so, where can I find an example/manual/tutorial), If you really really want to use as few libraries as possible, you could draw your text onto a pixmap, then rotate it to your window using XRenderSetPictureTransform and XRenderComposite. http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt#n705 http://cgit.freedesktop.org/xorg/lib/libXrender/tree/include/X11/extensions/Xrender.h#n267 Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: how can one build X without libxcb, or libxcb without python, or python without tcl/tk, or tcl/tk without X ?
On 2011-02-05 15:55, matti christensen wrote: - it appears to me that i'm not able to compile libxcb 1.7 without Python ( which i do not need or want on my system ) You only need Python to compile; you do not need it to run libxcb. Feel free to remove python when you are done, or cross-compile from another system. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: how can one build X without libxcb, or libxcb without python, or python without tcl/tk, or tcl/tk without X ?
On 2011-02-07 10:31, matti christensen wrote: i am afraid and don't like snakes. i downloaded libX 1.3.2 i really hope you get rid of such dependency to something that may or may not be in one's system = keep to basics Python isn't my favourite language either, but it's much better than the previous XSLT implementation. I don't think it's too much of a burden to expect python on a build machine. That said, if you think you can do a better job in a different language we'd love to see your alternative. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Distributed Multihead X
On 2011-02-01 20:56, tom fogal wrote: We're having some issues getting our software to work on a display well which is configured to use DMX. We're pretty sure the issue started coming up when we began dlopen()ing the OpenGL library. DMX doesn't support much of OpenGL. You might have better luck with Chromium. http://en.wikipedia.org/wiki/Chromium_%28computer_graphics%29 Although even Chromium looks like it hasn't been updated in a while. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XGetVisualInfo giving me a visual that doesn't work
On 2011-02-01 13:21, Greg Abram wrote: This looks like an X11 bug to me... this code creates a visual of depth 32, uses it to create a window, and blows up under the XMapRaised with BadMatch in X_CreateWindow. xdpyinfo shows that the selected visual is correctly a 32 bit TrueColor visual. If I request a 24 bit visual, its OK. If you use a non-default depth, you have to create your own colormap and border_pixel (or pixmap). The default (CopyFromParent) is what's causing your BadMatch. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: slow connection to X server
On 2010-11-12 02:09, Han wrote: my question is: in what kind of condition the X server would send large amount of data to client even before the Window show up? Wild guess: QueryFont on a large (unicode) font. Try using client side fonts to avoid this (eg. xterm -fa Courier -fs 10). Is there any debug tools to decode the data? Wireshark can decode core X11. Wireshark version 1.4 and later decode extensions, too. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [Xcb] [ANNOUNCE] xwininfo 1.1.0
On Mon, Sep 27, 2010 at 1:39 AM, Vincent Torri wrote: Nice work :) Though, I have 2 remarks: 1) Why a file for strnlen that is used only once in xwininfo.c ? The file isn't compiled at all on platforms where strnlen is available as part of libc. 2) You query at the beginning some netwm atoms. Just after, line 548, you can exit because the window with a name is not found. You should here get the replies of the requested atoms. If I'm not mistaken, you have to get the replies to free the memory in the server. You are mistaken. The replies will either be (a) in the socket buffers of your OS, which are freed when the socket is closed, or (b) in the client, which is freed by the OS when the client exits. In no case are pending replies stored in the server. Peter Harris ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Transparent Color in blitting with X11
On 2010-07-28 05:44, Rashid wrote: but xlib doesnt support an alpha channel (and the freerunner has only 16 bits per pixel). is there an easy way to do transparency (one transparent color is enough) with xlib or a toolkit which builds on it? If you can easily extract that color into a 1-bit bitmap, you can use XSetClipMask. Many GPUs accelerate the RENDER extension, so you can use XRenderCompose instead of XCopyArea to gain an alpha channel. (I'm not familiar with your particular GPU). If you want something higher level than Xlib, I hear good things about Cairo - http://cairographics.org/ - but I haven't used it myself. Btw. im doing the double buffering in a very stupid way. I write everything to a buffer and then copy the buffer to a window. Is there a faster and more clever way? No. You just have to be careful; if your toolkit already does double buffering, you'll wind up triple buffering. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Capturing X Traffic using ethreal
On 2010-07-13 09:14, sami md wrote: Is it possible to capture X protocol traffic using ethreal, Yes, although ethereal is deprecated in favour of wireshark. The display N listens and accepts connections on TCP port 6000+N, how to capture this traffic on ethreal? Many distros disable TCP by default. Make sure it is enabled on your machine. Then, export DISPLAY=tcp/localhost:0 before running your app. Also, make sure you're running wireshark as root (so it has permission to sniff traffic). Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [RE]Upgrading from 6.8.2
On 2010-02-24 12:59, paul rogers wrote: wget -r -np http://www.x.org/releases/X11R7.5/src/everything/ Alas, the occasional high-speed access I'll have would be using a friend's XP system--no wget, AFAIK. http://gnuwin32.sourceforge.net/packages/wget.htm Or just use your favourite download manager. There's nothing magic about wget. ftp://ftp.x.org/pub/X11R7.5/src/everything/*.bz2 if your favourite download manager happens to be an FTP client (FileZilla or similar). Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: reading a window's content with Xlib's XGetImage reveals portions of overlapping windows even with the backing store attribute set to Always
Amos Tibaldi wrote: I am trying to read the content of a portion of a window with the function XGetImage: but when I read the pixels in anImage-Data, if there is a window that overlaps the region that I read (0, 0, 200, 200), the content of that window is returned in anImage instead of the original content of the window. I have tried to set the backing store attribute of the window desktopWin to Always in order to see if that could help, in fact: 3.2.4 Backing Store Attribute Some implementations of the X server may choose to maintain the contents of InputOutput windows. Key words Some, may, choose. The BackingStore flag is just a hint. The server is not required to honour it. Unfortunately it has not helped, since overlapping portions of other windows are still returned in anImage instead of the original content of the window that I want to grab. What could I do to solve this matter? When drawing, draw to a pixmap then CopyArea the pixmap to your window. Do the GetImage on the pixmap instead of the window. Some toolkits do this automatically. All you'd have to do in that case is ask your toolkit for its backing pixmap instead of its window. Better yet, rework your code so you don't need to call GetImage. GetImage is very slow. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 1 Keyboard/Pointer, Many X Servers?
Hibiki Kanzaki wrote: I want to have several video display adapters/monitors with my computer, each with a corresponding X server, only one of which is actively receiving keyboard/pointer input at a given time. I have one keyboard/pointer attached to the computer. What are the simplest and best ways to configure things so I can switch the keyboard/pointer from one X server to another? (note: I do not want to have one X server span multiple displays, and I am not looking to have a single virtual desktop which seamlessly spans multiple X servers; I just want to be able to switch from one to another) I use Synergy: http://synergy2.sourceforge.net/ Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there a chance to set an alpha-mask using XOrg?
Leif Bergerhoff wrote: My intention is to draw a transparent image on a XScreen. How can I do this the best way? It depends on your toolkit. If you're not using any particular toolkit, the easiest way is to set _NET_WM_WINDOW_OPACITY on your window. See http://webcvs.freedesktop.org/xapps/transset/transSet.c?view=markup for an example. Make sure a composite manager is running (many desktops run one by default these days). Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
Patrick O'Donnell wrote: Date: Wed, 08 Apr 2009 08:36:29 -0700 From: Alan Coopersmith alan.coopersm...@sun.com Are there any systems in which you can write a million colors to a PsuedoColor colormap? I've not often seen PseudoColor supporting more than 8-bit/256 colors in the real world. I don't think the app was writing a million colors. I think it was designed for pixmaps with only a few colors and going insane on a JPEG. A million AllocColor requests, and a million (minus ~200) BadAlloc replies. I saw a 16-bit PseudoColor visual once, even recently. Too bad it didn't really work. (Can't recall the server that offered it.) That's... surprising. If you do remember which server offered it, I'd be interested to know what it was. The most I've seen is 12-bit PseudoColor (16bpp in order to keep the pixel granularity sane, but only 12 significant bits, and therefore 4096 colormap entries). Speaking of which -- the applications I'm maintaining are wedded to using a writable color map, which has always been PseudoColor, which, as you point out, pretty much means 8-bit. I've been toying with expanding the apps' repertoire to accepting a DirectColor visual, but I've noticed that not a lot of servers actually offer one. Would I be wasting my time adding in the necessary support for DirectColor? Probably. (Supporting TrueColor, alas, would be a royal pain, given the design of the apps.) At least one app I've seen would use an OpenGL fragment shader to do the PseudoColor = TrueColor translation at CopyArea[1] time. Instead of calling XStoreColors, you would load a new 1D texture and redo the copy. Unfortunately, I don't know of a way to bind an X Pixmap into an OpenGL texture, so that may not help you any. (The app in question was an OpenGL-based app, so all its info was in pbuffers to begin with). The RENDER extension already has mechanisms for copying PseudoColor pixmaps to TrueColor displays, but it does not allow you to use your own colormap. A new version of the RENDER extension with this feature added could be interesting[2]. I'm not sure if that helps you either, since I don't know if you have the time and energy to write the code and submit it for inclusion in future versions of the server. I also don't know if the X.org maintainers would balk at the idea. Peter Harris [1] Or whatever the OpenGL equivalent is called. [2] You'd need two new requests: RenderCreateFormat, which takes a colormap ID, and RenderCreateColormap, since the core CreateColormap takes a visual ID and the whole point of this is to get PseudoColor colormap support on servers that do not support a PseudoColor visual. -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
Patrick O'Donnell wrote: The RENDER extension already has mechanisms for copying PseudoColor pixmaps to TrueColor displays, but it does not allow you to use your own colormap. This sounds a bit more promising, though. I guess I'll have to read up on RENDER. Could you clarify it does not allow you to use your own colormap? Is there a default PseudoColor colormap (writable) that is uses, or is it a fixed colormap, and it's thus not really PseudoColor conversion that it's doing but StaticColor. If the default visual is PseudoColor, there will be a few writable color cells left in the default colormap. But in that case, you've already got a PseudoColor visual and don't need RENDER. If the default visual is not PseudoColor, every RENDER format that has a colormap will have one that is fully pre-allocated. That makes it effectively, as you say, StaticColor. Hence the part you trimmed about needing to improve RENDER slightly before it would be useful for your purposes. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Patrick O'Donnell wrote: From: Jim Gettys j...@freedesktop.org Date: Thu, 09 Apr 2009 15:25:26 -0400 We did fix it, with composite, in a way better than before. You don't have to run a compositing manager that does anything visual at all; you don't have to have one iota of transparency, drop shadows, or even anti-aliased fonts. It's not really the same, though, is it? It's a bit disingenuous to claim that it's a simple substitution, when in the one case the application merely sets a bit in the window attributes and in the other we have to find and configure (or write? I'm still not clear on that) a whole separate module with its attendant learning curve. And we have to make sure our customers install and configure it properly -- not an easy task, I can tell you! In my case (XFCE), it's as simple as cracking open the Window Manager Tweaks control panel and hitting the Enable display compositing checkbox. I assure you, this is far easier for your customers than the old method of enabling BackingStores and SaveUnders (which involved editing configuration files by hand, then restarting the X server - without which your 'merely sets a bit' would be ignored). I believe GNOME and KDE have an equivalent setting, enabled by default on many distributions. To be fair, you may have customers still using CDE or OpenLook. But those same customers are likely still using a SaveUnders capable X server too. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Patrick O'Donnell wrote: From: Peter Harris phar...@opentext.com ...Even if you do need to work on a PseudoColor display, you're far better off allocating a new Colormap[1] and calling XStoreColors once (to fill the whole Colormap with exactly the colors you need) for this sort of thing. But for nearly all systems, allocating a new colormap for specific windows creates color flashing when the windows change focus. Historically, yes. These days, I believe the scorecard reads: Linux: Default install is TrueColor only. Solaris: Default install is TrueColor only (?). AIX: Root visual is TrueColor, PseudoColor is available (no flashing unless some other app is already using the PseudoColor visual -- unlikely). IRIX: dead. But when it was alive, it often had multiple hardware colormaps (little or no flashing) even when the root visual was PseudoColor. MacOSX: Default install is TrueColor only. Windows: XP and newer needs gymnastics to use anything but TrueColor. X servers running on Windows mostly provide PseudoColor via emulation (infinite installed colormaps, no flashing). Embedded systems get to write their own rules, of course. When there are enough color slots avilable in the default colormap, XAllocColors (note the plural) gives a much more pleasing effect. Indeed. Working with the default colormap is preferable when you only need a few colors. (Though, I just really noticed the the million. That could indeed change the balance.) Yes, JPEG is, by definition, a TrueColor source image. Which is why I suggested allocating a new colormap (or, I guess, you could use a TrueColor visual for just the splash screen if one is available). You pretty much always want more than a few colors. So on the root colormap you're going to hit XAllocColor(Cells) allocation limits very quickly (ugly image), and you're going to suck up all the remaining color cells and leave none for any other application (impolite and/or DoS, depending on the resiliency of those other apps). Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Michel Dänzer wrote: On Wed, 2009-04-08 at 10:30 -0400, Patrick O'Donnell wrote: From: Michel =?ISO-8859-1?Q?D=E4nzer?= mic...@daenzer.net Date: Wed, 08 Apr 2009 15:58:18 +0200 On Wed, 2009-04-08 at 09:55 -0400, Patrick O'Donnell wrote: From: Michel =?ISO-8859-1?Q?D=E4nzer?= mic...@daenzer.net Date: Wed, 08 Apr 2009 15:29:28 +0200 On Wed, 2009-04-08 at 09:14 -0400, Patrick O'Donnell wrote: Unfortunately, that's not going to be available for all the platforms we must support. Why not? U... Because the servers on those platforms do not offer it? What are 'those platforms'? Which X.org servers offer neither the Composite extension nor backing store? The world is not all X.org. Not all the X servers on Windows that we have to deal with offer the Composite extension (or backing store -- sigh). Ah, I thought this was about X.org changes making things worse for you. Guess I lost track. :} It is. New X.org servers dropped SaveUnders. Many other X servers (including X.org builds from a couple of years ago) don't have the purported replacement. Now he has to support both. Needing to support both is worse than having to support only one. Honestly, SaveUnders and BackingStore were always just hints, so relying on them has always been broken. But that doesn't make his life any easier just now, so I can understand his frustration. As a constructive suggestion: For expensive drawing, you can draw to a pixmap and just copy from that pixmap to the window every time you get an Expose event. This should require relatively small changes to your code, and will work on all servers. The main downside is the lack of visible user-feedback while drawing, so you may want to implement a swirly or a progress bar or something so your users don't think the app has hung. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: Thanks. Is there any documentation on the best way to do various high-level tasks Xlib is all about low-level tasks, and very intentionally leaves high-level tasks to the various toolkits. In order to get much lower level than Xlib, you'd have to use write() directly on the socket... , such as drawing images? One of the big things I need to update is the toolkit's image-handling code: right now, a simple JPEG splashscreen takes seven seconds to draw. Seven seconds! The last time I saw a splashscreen take that long to draw, the app was doing a million XSetForeground/XDrawPoint pairs, instead of one single XPutImage. Without knowing exactly what you're doing, it is difficult to suggest improvements. A good howto on dealing with copy/paste would also be useful. As far as I know, not much has changed since the ICCCM was last updated ~15 years ago, aside from newer apps preferring the UTF-8 encoding for text. ICCCM: http://tronche.com/gui/x/icccm/sec-2.html#s-2 UTF8_STRING: http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/UTF8_STRING.text Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: On Tue, Apr 7, 2009 at 15:37, Peter Harris phar...@opentext.com wrote: Mark Wagner wrote: , such as drawing images? One of the big things I need to update is the toolkit's image-handling code: right now, a simple JPEG splashscreen takes seven seconds to draw. Seven seconds! The last time I saw a splashscreen take that long to draw, the app was doing a million XSetForeground/XDrawPoint pairs, instead of one single XPutImage. Without knowing exactly what you're doing, it is difficult to suggest improvements. I believe the slow part is a million calls to XAllocColor(). Since it works (if slowly), I haven't looked too closely at it. I've been concentrating on implementing features that are present in the Mac and Windows branches of the toolkit, but not the Linux branch. Yes, a million XAllocColor calls will hurt, since each one costs a round-trip. Over the network, that adds up to minutes. Even on a local display, that's still two million context switches. Unless you need to maintain support for legacy (PseudoColor) displays, there really isn't a reason to call XAllocColor any more. Even if you do need to work on a PseudoColor display, you're far better off allocating a new Colormap[1] and calling XStoreColors once (to fill the whole Colormap with exactly the colors you need) for this sort of thing. Hope that helps, Peter Harris [1] Please don't call InstallColormap - that's for window managers. Try both XSetWMColormapWindows (at the top level) and XChangeWindowAttributes (on each window and subwindow that needs the custom colormap). Yes, PseudoColor is a pain. Even more so on Windows, although that's down to taste (much like clipboards). Fortunately, PseudoColor seems to be mostly dead these days. -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Bug in Xextproto
Simon Thum wrote: INT32 type (and incompatible ones even, since Xmd's is unsigned long on ILP32 because whoever wrote Xmd.h is a C novice). (to be fair to whoever wrote Xmd.h, once upon a time X11 compiled and ran on I16LP32 targets) Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ximage's byte_order field
McDonald, Michael-p7438c wrote: Am I allowed to change the value of the XImage byte_order field? And if I do, will subsequent XPutImage() calls do the right thing? Yes, you can change the byte_order field to match the byte order of your image. XPutImage will take care of swapping your bits around to match what the server expects. See: http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/PutImage.c particularly the function SendZImage, if you want the gory details. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg memory leakage?
Stefano Avallone wrote: Hi all, I'm using xorg packages from experimental (xserver 1.5.99.901, libdrm 2.4.3, mesa 7.3-rc3, video-intel 2.6.1) and kde 4.2 (from experimental as well). I am using UXA+DRI2 and kwin with composite effects enabled. I am able to suspend and resume without problems. However, I noticed that the memory usage of Xorg slowly increases. After a couple of days of usage (with suspend and resume), top shows that the memory usage of Xorg is around 30% (I have 2GB RAM). At some point, the laptop becomes very slow, kwin automatically disables effects and I need to restart the server. Any advice how I could better debug this issue and provide useful information? Start with xrestop. It will give you a good idea of which apps are really responsible for the memory usage of Xorg. If xrestop comes up empty, then we can take a closer look at the X server itself. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Memory leak in fedora 8 xorg server 1.3
Barry Scott wrote: In miregion.c xfreeData macro: Why do a test on the size? Doesn't this lead to a leak of a malloc'ed block of memory? #define xfreeData(reg) if ((reg)-data (reg)-data-size) xfree((reg)-data) No. If the size is 0, then reg-data is miEmptyData (or the pixman equivalent in more recent servers). This is a static global, is shared amongst all single-rectangle regions, and can not be freed. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 peter.har...@opentext.com Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Window Manager and multiple application windows
Bipin George Mathew wrote: I actually did read about the the WM_HINTS window group in the ICCCM. In my experience, TRANSIENT_FOR is used far more often than WM_HINTS-group_window. To be more specific with my question, it is not compulsory for a client who creates multiple top-level windows to specify the window group hint - In that case I guess there is no way for the window manager to find out the top-level windows that belong to an application. Am I right? True, it is not mandatory. A single process can create multiple application windows. The window manager should treat these as separate applications. If a process wants a group of windows to belong to each other, it will set TRANSIENT_FOR (or WM_HINTS-window_group). You can look at the resource mask if you really need to know, but that would break ICCCM. Speaking of specs, you probably also want to support _MOTIF_WM_HINTS. It isn't an official X standard, but many apps use it to declare the decorations they want. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 peter.har...@opentext.com Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Get raw data of Xrender Picture structure
Gregoire Gentil wrote: - So, at this point, I consider more patching/hacking the window/compositing manager xfwm4 to add a screenshot when the window is about to be umapped. Patching something like no more unmap seems overkill for what I want to achieve. Using the Composite extension is the right way to redirect window contents. Let me know if you have any other comment or idea, Instead of re-inventing the wheel, you may wish to learn from Kompose. http://kompose.berlios.de/ Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Get raw data of Xrender Picture structure
Gregoire Gentil wrote: gdk_pixbuf_get_from_drawable returns garbage with a minimized windows and I think that xrender will return at least the outdated content of the window. Nope. XRender does not contain any functions that return the contents of a window, minimized or otherwise. Maybe you want the Composite extension. My windows and compositing manager is xfwm4 which doesn't support this feature. I'm then trying to shortcut xfwm4 and get what I want directly from Xrender. Sounds like you're trying to re-implement kompose? You might look there for ideas. http://kompose.berlios.de/ Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GLX in Xephyr --or-- is there some other way to catch a desktop in a texture?
Ashi Krishnan wrote: What I'm trying to do: I want to capture all the windows of some arbitrary X application as GL textures, then render them in some way, without any of this output showing up on screen (except where I finally render things, obviously). Sounds like Project Looking Glass or compiz-fusion. To get the window contents, I was going to redirect window contents to a texture with Composite / texture_from_pixmap. Yes, that would be the way to go about the problem. This is fine if (1) the app creates only one window, and (2) is quite cooperative with respect to where it draws that window -- like, say, the xscreensaver hacks. Maybe I'm dense, but I'm not seeing how that's a problem. Since you're acting as the window manager (you are 'managing' that window), you can manage all the windows of the application. You can decorate and compose them however you see fit. Ideas? Write a compiz-fusion plugin instead of reinventing the entire wheel? Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Get raw data of Xrender Picture structure
McDonald, Michael-p7438c wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clemens Eisserer If its a pixmap, you can read it back using XGetImage or its SHM variation. However keep in mind this is slow and suboptimal. What's the fast and optimal way? Don't read it back. Do your image manipulation entirely on the server side. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GLX in Xephyr --or-- is there some other way to catch a desktop in a texture?
Ashi Krishnan wrote: On Mon, Dec 8, 2008 at 2:20 PM, Peter Harris [EMAIL PROTECTED] wrote: Ashi Krishnan wrote: This is fine if (1) the app creates only one window, and (2) is quite cooperative with respect to where it draws that window -- like, say, the xscreensaver hacks. Maybe I'm dense, but I'm not seeing how that's a problem. Since you're acting as the window manager (you are 'managing' that window), you can manage all the windows of the application. You can decorate and compose them however you see fit. But I want to manage all the windows of that application and *only* the windows of that application. I'm not sure that's possible without being part of a larger framework (such as compiz-fusion) that manages the other windows. To do window management effectively, you pretty much need to select SubstructureRedirect on the root. Once you've done that, you have to be the window manager for the whole screen. And, as far as I'm aware, there's no reliable way of figuring out the pid of the process that owns a given window. Does _NET_WM_PID work reliably enough to be useful? _NET_WM_PID can be spoofed just as easily as any other property. Better than that, X is network transparent. You can have 30 different applications all running with the same PID, even without any _NET_WM_PID spoofing. I'm inclined to look at WM_NAME and WM_CLASS (in addition to _NET_WM_PID). From there, you can look at TRANSIENT_FOR and/or client mask bits of the xid to associate windows with each other. Writing a fusion plugin is a great idea, and I'll look into it, but I don't think it solves that problem. I'm not sure if compiz-fusion plugins can apply to single applications or not. If not, I'm sure it would still be easier to modify compiz-fusion to allow plugins to do so than to start from scratch. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Get raw data of Xrender Picture structure
McDonald, Michael-p7438c wrote: From: Peter Harris [mailto:[EMAIL PROTECTED] Don't read it back. Do your image manipulation entirely on the server side. Works as long as there is only one server side. Otherwise, slow and suboptimal seems to be your only choice. Fan out is another possibility. Chromium does this for OpenGL; I'm sure you could do something similar in the 2D space if you needed it. It does have the potential to use more resources on each server. In return you avoid GetImage, which is very slow. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how does X clip ?
My Own Linux wrote: Assume I have a Window boundary of (0,0) to (200,200) If I give a command to XDrawLine or anything else from coordinate (100,100) - 400,400) How does X clip the pixel lying outside the Window boundary (the algorithm) ? The clip region calculation algorithm is implemented in: http://cgit.freedesktop.org/xorg/xserver/tree/mi/mivaltree.c Actually clipping to that region is left up to the driver most of the time, and may be implemented in hardware. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
McDonald, Michael-p7438c wrote: I'm trying to run the Xorg server using the dummy driver in the background in Linux. Everything works fine as long as the dummy Xorg has the VT focus. If it's in the background, then XGetImage returns junk data. XGetImage *always* returns junk data. The actual bits are highly dependant on BackingStores and/or obscuring of your particular window and/or XSECURITY and/or XACE settings. And possibly Composite settings too, although I haven't checked that particular extension for GetImage interactions. Basically, unless you are taking a screen shot, XGetImage is the wrong thing to do. And if you *are* taking a screen shot of a screen that has switched to another VT, junk is the correct result. Although I suppose you could argue that the junk should be overwritten with a regular pattern, such as that created by XaceCensorImage, as the junk may be a security leak. It seems like the VT code is somehow causing the framebuffer to get swapped out. Can someone give me a hint as to what's going on? And how to work around it if there is a work around? Workaround (or, arguably, bug fix): Don't use XGetImage. Alternate workaround (or, arguably, bug fix): Use XGetImage only on Pixmaps, never Windows. (Ditto for the source drawable of CopyArea/CopyPlane). Potential alternate workaround, depending on what exactly you are doing: Make sure BackingStore is enabled for your particular window. As you can see on page 57 of the X protocol reference, this is the only reliable way to get the bits of an obscured window (and a window is definitely obscured if the VT has been switched). Most Linux distributions ship with BackingStore disabled, though, so this isn't viable if you want your app to run everywhere. Also, the BackingStore bit is just a hint. Even if the server claims to support the BackingStore bit, it is free to discard your BackingStore at any time, although few servers do so. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
Alan Cox wrote: Speed of switching for one. Nothing like copying several megabytes of data from a PCI/AGP card via PIO to make life suck. Indeed. Presumably GetImage should either block or cause a redraw into an offscreen pixmap ? GetImage can't block while waiting for a redraw, since the app requesting the GetImage is often the same app that needs to do the redraw (and will itself be blocked waiting for a GetImage reply). But that's okay, since GetImage was effectively deprecated on day one: This request is not general-purpose in the same sense as other graphics-related requests. It is intended specifically for rudimentary hardcopy support. GetImage contents are undefined if the window is obscured (which it certainly is if the framebuffer is gone). Presumably, GetImage should simply return a black rectangle in that case. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
McDonald, Michael-p7438c wrote: I'm only doing XGetImage on the root window. Is your application prepared to handle undefined bits for windows that are not the same depth as the root? (Overlays, for example, but also non-sample servers make multiple depths available). As far as I'm aware, root windows only have one depth. I believe that holds for every individual window as well: a window has a single depth, which may differ from its parent's and its sibling's depths. Exactly. And XGetImage always includes inferior windows[1]. When those inferiors are a different depth, those contents of XGetImage are undefined[2]. Think about what happens when the root is depth 8, and your application intelligently picks a depth 24 visual for its display. Your monitor will display the full 24-bit image just fine, but a lossless translation for XGetImage simply isn't possible. The protocol definition doesn't even suggest an approximation. In the X protocol, there is no concept of the root window being obscured. I don't see why not. If I am running multiple desktops, the root of one desktop may be obscured if I am viewing a different desktop. Consider Xnest (and Xephyr), which can have its root window obscured by other windows on the host server. Consider also a virtual root that is larger than the resolution of your monitor. Traditionally, the sample implementation has saved the bits that are not visible, but there is no reason it needs to (other than performance). Peter Harris [1] Yes, that was a stupid protocol design decision. But at least the protocol designers admit it in the docs: This request is not general-purpose... It is intended specifically for rudimentary hardcopy support. [2] http://cgit.freedesktop.org/xorg/doc/xorg-docs/plain/hardcopy/XProtocol/proto.PS.gz -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
Peter Harris wrote: McDonald, Michael-p7438c wrote: In the X protocol, there is no concept of the root window being obscured. I don't see why not. If I am running multiple desktops, the root of one desktop may be obscured if I am viewing a different desktop. I forgot to remind you about Xsecurity/Xace. In a properly secured setup, any attempt to do an XGetImage on the root window will result in BadAccess (and no image); doing a GetImage on your own bottommost root-sized window will result in an empty image. This isn't just theoretical; SSH -X tunnels typically set this up by default, for example. In this case, you might as well imagine that the root window is obscured, at least from the perspective of your application. The obscuring is artificial, granted, but still present. Your app isn't allowed to see bits from other applications, so it doesn't. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: git and utf16
Jeremy Huddleston wrote: Does anyone know if there's a way I can tell git that a file is utf16 text so it treats it more intelligently than a binary file? You could try using .gitattributes to see if you could come up with something that works. git help gitattributes The first thing that springs to mind is a clean/smudge filter (using iconv or similar) to actually store the file in UTF-8, and only keep it in UTF-16 in the checkout, although that would require all users of Localizable.strings to configure the filter to get a functional file. I'm not sure how the below email was generated, but setting .gitattributes to use an external diff command that groks UTF-16 may help. Just setting the 'diff' attribute will tell git that the file is text, but it may not be what you want (UTF-16 tends to be poorly readable when interpreted as Latin-1). Peter Harris Begin forwarded message: From: [EMAIL PROTECTED] (Jeremy Huddleston) Date: October 21, 2008 19:37:20 PDT To: [EMAIL PROTECTED] Subject: xserver: Branch 'xorg-server-1.4-apple' hw/xquartz/bundle/Resources/English.lproj/Localizable.strings |binary 1 file changed New commits: commit e9fe3f36d9529f00daeefa1379cdd6f01a88f410 Author: Jeremy Huddleston [EMAIL PROTECTED] Date: Tue Oct 21 19:36:48 2008 -0700 XQuartz: Added missing semicolons to Localizable.strings diff --git a/hw/xquartz/bundle/Resources/English.lproj/Localizable.strings b/hw/xquartz/bundle/Resources/English.lproj/Localizable.strings index dc19fc9..fec942e 100644 Binary files a/hw/xquartz/bundle/Resources/English.lproj/Localizable.strings and b/hw/xquartz/bundle/Resources/English.lproj/Localizable.strings differ ___ xorg-commit mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg-commit ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Dispatching and scheduling--basic questions
Adam Jackson wrote: Lock cost on x86 is relatively cheap on one die. If you go off the die, just pack it up and go home. Admittedly this is a scaling problem only for things you do millions of per second, which is not true of atoms/properties/misc... ...but is true of XID lookups. You could alleviate this somewhat by using a finer grained lock - most clients access only their own resources. But that doesn't help the Window Manager. Still I don't like the complexity explosion. That too. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
