Re: non-clipped child windows
On 2015-07-04 06:46, Cosmin Apreutesei wrote: > Does X have the notion of non-clipped child windows? The behavior in > WIndows and OSX for these is: > > 1) the parent always stays behind its children > 2) the children are closed automatically when the parent is closed > 3) the children follow the parent when moving > > If the answer is no, then I can emulate 2 and 3 but how about 1? 1) is usually implied by the WM_TRANSIENT_FOR property, although it can vary depending on window manager. 2) WM_TRANSIENT_FOR will minimize transient windows when their parent is minimized. I don't think the spec says anything about closing. 3) you will probably have to emulate 3. http://www.x.org/releases/X11R7.7/doc/xorg-docs/icccm/icccm.html#WM_TRANSIENT_FOR_Property http://standards.freedesktop.org/wm-spec/latest/ar01s09.html#STACKINGORDER 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.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Need a reference to X protocol documentation for shapemask in transparent xpm
On 2013-10-29 04:27, Michael Enke wrote: > Hello Alan, > thank you for your comment. > I was playing with XServer for Android and created a patch to support > "transparency" > using the core protocol. Now the maintainer (and me too), before adding > that patch, > would like to know where to find this in the documentation. > Searching the x11protocol.pdf for "transparent" matched one place which > is not related to > "transparency". > Any hint? http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:CreateGC Search for "clip-mask". 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.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: PseudoColor X - Initial entries in the shared colormap
On 2013-03-13 13:15, Andy Bristow wrote: > When using X in 8-bit PseudoColor mode, I am trying to find out where > default colors are allocated to the system colormap. > > When I start just X - by that I mean just the root window displayed: > without a display manager and without any application windows (not even > so much as an Xterm), then the colormap has already 73 entries in it. > Does anyone know how they get there? I was expecting black and white in > there (there is the cursor to display, after all), but 73? > > If I could find out how they get there, then I may be able to reduce the > number ... The RENDER extension preallocates a colour cube. You can reduce the number of preallocated entries by disabling RENDER, but be aware that most modern apps require RENDER to run. 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.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XLib Help : RGBA Visual and Window Creation
On 2012-04-23 16:53, Lee Fallat wrote: > > In fact, that was one problem, but now I am getting a Bad Match "Invalid > Parameters" error. Same code with dc.vinfo->class changed to > InputOutput/CopyFromParent. Any suggestions for that? > CWOverrideRedirect|CWColormap|CWEventMask, You also need to set the border pixel and background pixel when creating a window of a different depth than its parent. 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.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XDrawLine and optimization
On 2012-03-02 17:03, Christopher Howard wrote: > On 03/02/2012 12:41 PM, Adam Jackson wrote: >> On 3/2/12 4:21 PM, Christopher Howard wrote: >>> I don't have much (any?) Xlib programming savvy, but before diving >>> headlong into the Programming Manual I was hoping to get some >>> perspective. There is a particular application I use pretty often, and >>> one of the things it does is to draw filled line graphs on the screen, >>> which it does by calling XDrawLine() with the appropriate parameters for >>> each data point. Looking at the code, I was curious if I could optimize >>> this, by first drawing everything into some kind of local memory buffer >>> and then passing that into some Xlib function all at once. >>> >>> However, since XDrawLine() presumably draws the lines into a buffer >>> anyway, I'm wondering if there are any realistic gains (or any gains at >>> all) to be had by such an approach. >> >> Might or might not help. It really depends more what kind of lines >> you're drawing - in particular what the GC state is you're using to draw >> them and the characteristics of the surface you're drawing to - and >> which driver you're using. Can you give more detail? >> >> - ajax >> > > > The code is from conky.c in conky-1.8.1. Before the loop it does one > > code: > -- > XSetLineAttributes(display, window.gc, 1, LineSolid, > CapButt, JoinMiter); > -- If you use a line width of 0 (not 1) it is more likely that the driver can use hardware acceleration (although this is more likely applicable to older drivers). If you can use XRenderCompositeTrapezoids instead of XDrawLine, this may be faster with newer drivers. As a bonus, XRender optionally provides antialiasing. (A library such as Cairo http://cairographics.org/ will be much easier to use than bare XRender). > And each actual line draw is preceded by a call to XSetForeground (the > color changes in different parts of the graph). That's going to hurt if you're using a remote server. Xlib won't be able to coalesce the lines into a single request, so the app will be using a lot of bandwidth (36 bytes per line, if I've added it up right). So if you're drawing a million lines (I'm not familiar with conky, but it's not unreasonable for some applications) it uses less bandwidth to draw it yourself and do a PutImage at the end, unless your buffer is larger than 8 megapixels or so. On a local server, it doesn't make as much difference. 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.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
