libXrender issueshttps://gitlab.freedesktop.org/xorg/lib/libxrender/-/issues2018-08-10T20:02:33Zhttps://gitlab.freedesktop.org/xorg/lib/libxrender/-/issues/2XRenderComposite source coordinate + matrix inefficiencies2018-08-10T20:02:33ZBugzilla Migration UserXRenderComposite source coordinate + matrix inefficiencies## Submitted by Roderick Colenbrander
Assigned to **Xorg Project Team**
**[Link to original bug (#22918)](https://bugs.freedesktop.org/show_bug.cgi?id=22918)**
## Description
Created attachment 27960
Test program which illustrates...## Submitted by Roderick Colenbrander
Assigned to **Xorg Project Team**
**[Link to original bug (#22918)](https://bugs.freedesktop.org/show_bug.cgi?id=22918)**
## Description
Created attachment 27960
Test program which illustrates the issue
Hi,
Specification of source x / y coordinates in a identity transformation matrix instead of passing them to XRenderComposite is a lot slower. This is because XRender applies optimizations for identity matrices and it doesn't consider the use of x/y coordinates in the matrix as such. I think that internally XRender should be changed to put x/y coordinates in the matrix by default. At least it shouldn't be the task of the client to 'detect' this issue (in Wine I now have to add additional code to handle this which increases complexity).
Some simple tests using the attached test app on FGLRX which only has a software xrender implementation (on nvidia drivers the hit is only a factor 2 or so).
433966.985996 Ops/s; Simple Blit (!); 20x20
125044.647547 Ops/s; Simple Blit (!); 100x100
8678.437881 Ops/s; Simple Blit (!); 500x500
431653.551514 Ops/s; Simple Blit Offset (!); 20x20
125829.403664 Ops/s; Simple Blit Offset (!); 100x100
8522.315519 Ops/s; Simple Blit Offset (!); 500x500
113033.378164 Ops/s; Transformed Blit Linear (!); 20x20
6806.220993 Ops/s; Transformed Blit Linear (!); 100x100
287.979924 Ops/s; Transformed Blit Linear (!); 500x500
Thanks,
Roderick Colenbrander
Wine developer
**Attachment 27960**, "Test program which illustrates the issue":
[xrender_test.c](/uploads/218ff1e7e284172efd55996cdb3ecaf1/xrender_test.c)https://gitlab.freedesktop.org/xorg/lib/libxrender/-/issues/1Crash in XRenderComputeTrapezoids()2022-10-22T01:14:02ZBugzilla Migration UserCrash in XRenderComputeTrapezoids()## Submitted by Trond Kjernasen
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#1017)](https://bugs.freedesktop.org/show_bug.cgi?id=1017)**
## Description
I think I've found a bug in the Xrender library. The foll...## Submitted by Trond Kjernasen
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#1017)](https://bugs.freedesktop.org/show_bug.cgi?id=1017)**
## Description
I think I've found a bug in the Xrender library. The following little bit of
code crashes for me on any of the Linux systems that I've tried it on (a
compileable test program is available here:
http://trolls.troll.no/trond/xrender_bug.tgz):
...
case Expose: {
XExposeEvent * ev = (XExposeEvent *) &event;
XftColor xfc;
const uint A = 127,
R = 255,
G = 255,
B = 255;
xfc.pixel = 0x0;
xfc.color.alpha = (A | A << 8);
xfc.color.red = (R | R << 8) * xfc.color.alpha / 0x10000;
xfc.color.green = (B | G << 8) * xfc.color.alpha / 0x10000;
xfc.color.blue = (B | B << 8) * xfc.color.alpha / 0x10000;
Picture src = XftDrawSrcPicture(xft_hd, &xfc);
Picture dst = XftDrawPicture(xft_hd);
XPointDouble poly[4] = {{76.0, 29.0}, {69.0, 27.0}, {52.0, 25.0},
{52.0, 26.0}};
XRenderCompositeDoublePoly(dpy, PictOpOver, src, dst,
XRenderFindStandardFormat(dpy,
PictStandardARGB32),
0, 0, 0, 0, poly, 4, 1);
}
...
GDB backtrace is here:
```
Program received signal SIGSEGV, Segmentation fault.
0x40254dd4 in XRenderComputeTrapezoids (edges=0x805a5f0, nedges=4, winding=1,
traps=0x806afe8) at Poly.c:197
197 traps->right = en->edge;
(gdb) bt
#0 0x40254dd4 in XRenderComputeTrapezoids (edges=0x805a5f0, nedges=4,
winding=1, traps=0x806afe8) at Poly.c:197
#1 0x402550ec in XRenderCompositeDoublePoly (dpy=0x804a008, op=3,
src=60817412, dst=60817413, maskFormat=0x8053d28, xSrc=0, ySrc=0, xDst=0,
yDst=0, fpoints=0xbfffe440, npoints=4, winding=1) at Poly.c:296
#2 0x08048acf in event_loop (dpy=0x804a008) at crash1.c:64
#3 0x08048b6d in main (argc=1, argv=0xbfffe5d4) at crash1.c:87
```
Valgrind output for here:
[snip]
==3959== Invalid write of size 4
==3959== at 0x40484DA4: XRenderComputeTrapezoids (Poly.c:194)
==3959== by 0x404850EB: XRenderCompositeDoublePoly (Poly.c:296)
==3959== by 0x8048ACE: event_loop (crash1.c:64)
==3959== by 0x8048B6C: main (crash1.c:87)
==3959== Address 0x414D9F20 is 0 bytes after a block of size 768 alloc'd
==3959== at 0x4002ACB4: malloc (in /usr/lib/valgrind/vgskin_memcheck.so)
==3959== by 0x40484F07: XRenderCompositeDoublePoly (Poly.c:242)
==3959== by 0x8048ACE: event_loop (crash1.c:64)
==3959== by 0x8048B6C: main (crash1.c:87)
[snip]
There is an out-of-bound write in the line above, and it seems that there is
too little space allocated to "traps" (or really, the "edges" var) in certain
situations.
I'd appreciate it if anyone can confirm that this is actually a bug. Thanks.
--
Regards,
Trond K.Keith PackardKeith Packard