Re: Compositing issues with 30-bit RGB visuals
Am 18.10.11, 20:10 -0700 schrieb Pierre-Loup A. Griffais: On 10/17/2011 11:41 PM, Kai-Uwe Behrmann wrote: I am not sure where to start and seek for input on a problem with KWin and Compiz. They show very similiar wrong rendering of borders, shadows and the logout screens. In compiz is a RGBA buffer used to contruct window borders and shadows: /* all pixmaps are ARGB32 */ format = XRenderFindStandardFormat (xdisplay, PictStandardARGB32); A sreenshot suggests that the 8-bit buffers are blended as is into the 30-bit visuals. What is the correct way to blend in the final frame buffer image with XRenderComposite()? Is the problem that the destination picture is created with the wrong format? To create a Picture around the root window, the WM probably wants to use PICT_a2r10g10b10 when it's depth 30 instead. XRenderFindStandardFormat() accepts PictStandardARGB32 as the highest per channel bit depth format. Seems like I have to figure out how to contruct a XRenderPictFormat structure including XRenderDirectFormat. Here is some basic description: http://www.x.org/releases/current/doc/libXrender/libXrender.txt A example is given in the nvidia docu: http://ftp.iinet.net.au/pub/nvidia/freebsd/169.12/README/README Are you trying to fix the same bug that I reported a while back? https://bugs.kde.org/show_bug.cgi?id=214011 It looks similiar, giving a hint that it might be the same effect. As a side note, the window contents are almost fine with the exception of FF and GTK2 drawing areas. I believe Damien Leone (CCed) came up with a patch for GTK that should fix the issue you're seeing? He attached it to a bug you filed back in July: https://bugzilla.gnome.org/show_bug.cgi?id=625202 Have you tried applying that to see if it fixes the non-WM related issues you're seeing? Thanks for the patch and as well for pointing to. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ 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: Compositing issues with 30-bit RGB visuals
On 10/19/2011 12:24 AM, Kai-Uwe Behrmann wrote: Am 18.10.11, 20:10 -0700 schrieb Pierre-Loup A. Griffais: On 10/17/2011 11:41 PM, Kai-Uwe Behrmann wrote: I am not sure where to start and seek for input on a problem with KWin and Compiz. They show very similiar wrong rendering of borders, shadows and the logout screens. In compiz is a RGBA buffer used to contruct window borders and shadows: /* all pixmaps are ARGB32 */ format = XRenderFindStandardFormat (xdisplay, PictStandardARGB32); A sreenshot suggests that the 8-bit buffers are blended as is into the 30-bit visuals. What is the correct way to blend in the final frame buffer image with XRenderComposite()? Is the problem that the destination picture is created with the wrong format? To create a Picture around the root window, the WM probably wants to use PICT_a2r10g10b10 when it's depth 30 instead. XRenderFindStandardFormat() accepts PictStandardARGB32 as the highest per channel bit depth format. Seems like I have to figure out how to contruct a XRenderPictFormat structure including XRenderDirectFormat. Here is some basic description: http://www.x.org/releases/current/doc/libXrender/libXrender.txt A example is given in the nvidia docu: http://ftp.iinet.net.au/pub/nvidia/freebsd/169.12/README/README Yes, I believe just calling XRenderFindVisualFormat() on the Window visual is what you want to do instead of always using PictStandardARGB32. Thanks, - Pierre-Loup Are you trying to fix the same bug that I reported a while back? https://bugs.kde.org/show_bug.cgi?id=214011 It looks similiar, giving a hint that it might be the same effect. As a side note, the window contents are almost fine with the exception of FF and GTK2 drawing areas. I believe Damien Leone (CCed) came up with a patch for GTK that should fix the issue you're seeing? He attached it to a bug you filed back in July: https://bugzilla.gnome.org/show_bug.cgi?id=625202 Have you tried applying that to see if it fixes the non-WM related issues you're seeing? Thanks for the patch and as well for pointing to. kind regards Kai-Uwe Behrmann ___ 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
Compositing issues with 30-bit RGB visuals
I am not sure where to start and seek for input on a problem with KWin and Compiz. They show very similiar wrong rendering of borders, shadows and the logout screens. In compiz is a RGBA buffer used to contruct window borders and shadows: /* all pixmaps are ARGB32 */ format = XRenderFindStandardFormat (xdisplay, PictStandardARGB32); A sreenshot suggests that the 8-bit buffers are blended as is into the 30-bit visuals. What is the correct way to blend in the final frame buffer image with XRenderComposite()? As a side note, the window contents are almost fine with the exception of FF and GTK2 drawing areas. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ 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: Compositing issues with 30-bit RGB visuals
On 10/17/2011 11:41 PM, Kai-Uwe Behrmann wrote: I am not sure where to start and seek for input on a problem with KWin and Compiz. They show very similiar wrong rendering of borders, shadows and the logout screens. In compiz is a RGBA buffer used to contruct window borders and shadows: /* all pixmaps are ARGB32 */ format = XRenderFindStandardFormat (xdisplay, PictStandardARGB32); A sreenshot suggests that the 8-bit buffers are blended as is into the 30-bit visuals. What is the correct way to blend in the final frame buffer image with XRenderComposite()? Is the problem that the destination picture is created with the wrong format? To create a Picture around the root window, the WM probably wants to use PICT_a2r10g10b10 when it's depth 30 instead. Are you trying to fix the same bug that I reported a while back? https://bugs.kde.org/show_bug.cgi?id=214011 As a side note, the window contents are almost fine with the exception of FF and GTK2 drawing areas. I believe Damien Leone (CCed) came up with a patch for GTK that should fix the issue you're seeing? He attached it to a bug you filed back in July: https://bugzilla.gnome.org/show_bug.cgi?id=625202 Have you tried applying that to see if it fixes the non-WM related issues you're seeing? Thanks, - Pierre-Loup kind regards Kai-Uwe Behrmann ___ 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
Visuals
Hi, When i do xpyinfo, i get 29 visuals the same: visual: visual id:0xdc class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0xdd class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0xde class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits ... visual: visual id:0xf9 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits Why isn't there just one of each type of visual? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Visuals
On Tue, Jan 05, 2010 at 01:01:08PM +1100, Russell Shaw wrote: When i do xpyinfo, i get 29 visuals the same: [...] Why isn't there just one of each type of visual? If you look at the output of glxinfo, you'll see that each visual has different GL attributes. Cheers, Daniel pgpBLfAxIv5Il.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
Date: Thu, 9 Apr 2009 01:14:28 +0200 From: Olivier Galibert galib...@pobox.com On Wed, Apr 08, 2009 at 07:00:02PM -0400, Patrick O'Donnell wrote: 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? (Supporting TrueColor, alas, would be a royal pain, given the design of the apps.) You would be. On the other hand, are you sure supporting DirectColor is any easier than TrueColor? The hard part, supported 255 color numbers, seems to be identical, and the 3 per-color palettes don't allow for much in terms of color animation. Our use of the writable color map centers on using a handful of color planes ot layer our graphics and simplify drawing and redrawing on the separate layers. For that purpose, at least, it turns out that the number of colors, pixel depth, and palettes don't complicate matters very much -- that turns out not to be the hard part. In fact, though I haven't done the conversion in our main toolkit, a proof-of-concept test app was /very/ easy to convert from PseudoColor to DirectColor. The key for us is the writability of the colormap. Assumptions about that rise up into more application code than I'd care to deal with. At least one of our applications assumes it can change the color map to highlight different aspects of the information. If both PseudoColor and DirectColor die, we will be faced with a much bigger challenge than dropping of save-under support (!). From: Glynn Clements gl...@gclements.plus.com Date: Thu, 9 Apr 2009 01:01:04 +0100 So much stuff breaks with a DirectColor visual that no-one ever uses one. By this, I presume you mean that many clients fail to support DirectColor correctly, (or fail to match visuals correctly) so they break? Or are you referring to server support for DirectColor failing often? - Patrick ___ 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?)
Date: Thu, 09 Apr 2009 11:17:25 -0400 From: Peter Harris phar...@opentext.com Patrick O'Donnell wrote: (Supporting TrueColor, alas, would be a royal pain, given the design of the apps.) ... use an OpenGL fragment shader to do the PseudoColor = TrueColor translation at CopyArea[1] time. ... Unfortunately, I don't know of a way to bind an X Pixmap into an OpenGL texture, so that may not help you any. Thanks for the idea, but I think you're right that it probably is not the direction to go. 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. - Pat ___ 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: PseudoColor and DirectColor visuals (was Re: Documentation?)
Patrick O'Donnell wrote: So much stuff breaks with a DirectColor visual that no-one ever uses one. By this, I presume you mean that many clients fail to support DirectColor correctly, (or fail to match visuals correctly) so they break? Or are you referring to server support for DirectColor failing often? Clients. Either they print a not supported error message, or just assume that the default colourmap has full-scale monotonic ramps and treat it as TrueColor. If you're really lucky, they'll allocate a private colourmap, set linear ramps, then treat it as TrueColor. The number of programs which break with a DirectColor visual suggests that they're essentially a theoretical concept which doesn't occur in practice. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
On Wed, Apr 08, 2009 at 07:00:02PM -0400, Patrick O'Donnell wrote: 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? (Supporting TrueColor, alas, would be a royal pain, given the design of the apps.) You would be. On the other hand, are you sure supporting DirectColor is any easier than TrueColor? The hard part, supported 255 color numbers, seems to be identical, and the 3 per-color palettes don't allow for much in terms of color animation. OG. ___ 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: 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. So much stuff breaks with a DirectColor visual that no-one ever uses one. The main problem with relying upon a PseudoColor visual is that the hardware support could quite quickly go the way of floppy drives and serial and parallel ports. The only reason the chipset vendors still provide hardware VGA compatibility is that safe mode relies upon it. If they ever figure out how to eliminate that requirement, the video palette will disappear overnight. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Multiple Visuals in Server
Hi, I am trying to figure out how to configure my X server to create multiple visuals. When I ran xdpyinfo, it returned 57 visuals 56 had a depth of 24, and one had a depth of 32. I was hoping to get at least one visual of depth 8 and one visual of depth 16. Is this possible? If so where should I start? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
