Daniel Stone <[email protected]> writes: > You're right that it makes little to no sense to mix the two, but I'm > not sure what practical gain we get from expressing things as > Pictures.
Well, abstractly, a Picture can represent any of the formats you've talked about -- they have explicit knowledge of color and translucency, and already provide a notion of 'source only' objects which need not store ARGB values for each pixel. > Ultimately, the server still deals in Window Pixmaps and > Screen Pixmaps for backing storage, and the compositor interface is > NameWindowPixmap. Your suggestion of another type seems nicer, but it > doesn't look like we can avoid Pixmaps as the lowest common > denominator anyway. What's the plan for compositors which just want to turn window contents into textures? I'd assume you'd want to update them to understand the new format bits, which leaves us free to do something sensible here. For X-based compositors (are there any left?), we can fake out the pixmap easily enough (NameWindowPixmap creates a suitable 'real' pixmap, CopyArea/Composite update the source region before the copy happens). > That would much more clearly match the intention of the spec > additions, which was to allow non-linearly-addressed (Intel X/Y*, > Vivante tiled/supertiled, VC4 T-tiled, the infinite AMD/NV tiling > modes) buffers. I'm confused -- I can't see how tiling is relevant here; if you're storing actual ARGB pixels, even in some crazy order, then you've got a pixmap. I have to admit that all I know about is Intel X/Y tiling though; are there ways in which the other tiling formats don't just store ARGB pixels? > tl;dr: we could replace FourCC with depth as the format determinant to > better match DRI3 v1.0, or just declare that doing anything with those > Pixmaps other than displaying them to a Window with a compatible > Visual results in undefined behaviour Hrm. I think I'm stuck on the notion that Pixmaps are concrete 2D arrays of multi-bit values. What about calling them 'source pixmaps' and offering extended requests to determine the precise nature of the data within? Make core requests report correct width and height values, and then fix them at depth 24 for RGB or depth 32 for ARGB. Using them as a rendering target could generate BadMatch, or be ignored (I'd prefer the former). DRI3BufferFromPixmap could create a shadow 'normal' pixmap and use Damage to sync it with the source pixmap. Creating a Picture from a 'source pixmap' could dtrt (at least at some point; it could also just use a shadow pixmap). A new DRI3BufferFromSourcePixmap request would be used to get the list of buffers and appropriate format data so that updated compositors could get improved results. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
