If the driver isn't compatible to the server, all bets are off anyway wrt
the contents of the fields that we're validating, which can lead to bogus
error messages.
The only functional changes in this patch are a removal of use of
Xtrans internals -- replaced by xcb, which doesn't seem to be used
elsewhere in the server? Pity.
Also, a fix to make all X11 windows pop to the front of the display
when the X11.app icon is clicked -- currently takes two clicks,
not sure why.
At least on my system (10.5 with the latest and greatest modules),
Xquartz now builds out of the box. It doesn't quite work yet, but
hey -- you have to start somewhere. ;)
this fixes a breakage caused by 7a4ec34e25.
When running a non DTRACE aware system that is not darwin*, DTRACE was getting
required. Now it is not anymore.
This was an attempt to avoid scratch gc creation and validation for paintwin
because that was expensive. This is not the case in current servers, and the
danger of failure to implement it correctly (as seen in all previous
implementations) is high enough to justify removing it. No performance
difference detected with x11perf -create -move -resize -circulate on Xvfb.
Leave the screen hooks for PaintWindow* in for now to avoid ABI change.
Instead of drawing to window pixmap for everything, draw to window for
background as that works for Xnest and Xdmx; draw to pixmap for borders
which neither of those X servers use.
miPaintWindow was drawing to the root window, or (sometimes) drawing to the
window after smashing the window clip list. This is losing, and easily fixed
by just drawing to the window pixmap.
Because our "popen" implementation uses stdio, and because nobody's stdio
library is capable of surviving signals, we need to make absolutely sure
that we hide the SIGALRM from the smart scheduler. Otherwise, when you
open a menu in openoffice, and it recompiles XKB to deal with the
accelerators, and you popen xkbcomp because we suck, then the scheduler
will tell you you're taking forever doing something stupid, and the
wait() code will get confused, and input will hang and your CPU usage
slams to 100%. Down, not across.
Improve exaShmPutImage performance and reuse its core in exaPutImage as it
seems faster than the previous code when the driver doesn't provide an
UploadToScreen hook.
Make sure all damage records are notified of the damage incurred by actual
ShmPutImage calls.
Remove superfluous manual damage tracking for actual PutImage calls.
Exclude bits that will be overwritten from migration.
Use exaGlyphs even when Composite can't be accelerated, to avoid PolyFillRect
roundtrip via offscreen memory.
Initialize mask pixmap in exaGlyphs in FB in addition to system if the driver
provides Composite hooks to avoid migration overhead.
Remove manual damage tracking where superfluous.
Initialize system and FB copy in exaFillRegionSolid and adapt
exaGetPixmapFirstPixel to the new migration infrastructure.
This should mostly eliminate migration overhead for these, whether they are
used for acceleration or fallbacks.
As we can't actually accelerate anything interesting here, just migrate out
once and call fbSolidBoxClipped instead of taking a round trip via offscreen
memory with exaSolidBoxClipped.
Reuse pending damage region for extents and to prevent any actual migration of
pixmap contents when we're overwriting the whole pending damage region.
Remove superfluous manual damage tracking.
Only migrate once in exaTrapezoids/Triangles instead of every time in
exaRasterizeTrapezoid/AddTriangles. Adapt manual damage tracking to new
infrastructure.
Also move definition of NeedsComponent() closer to where it's used.
We finally want to catch all cases where the pixmap pointer is dereferenced
outside of exaPrepare/FinishAccess.
Also fix a couple of such cases exposed by this change.
