Skip to content

Build the X11 backend without wraster by default - #177

Open
DTW-Thalion wants to merge 4 commits into
gnustep:masterfrom
DTW-Thalion:fix/wraster-server-xlibimage
Open

Build the X11 backend without wraster by default#177
DTW-Thalion wants to merge 4 commits into
gnustep:masterfrom
DTW-Thalion:fix/wraster-server-xlibimage

Conversation

@DTW-Thalion

@DTW-Thalion DTW-Thalion commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Dependencies: Needs PR #175 to be merged.

This adds an --enable-wraster configure option and makes the X11 server and the xlib graphics backend build without wraster by default.

A new Source/x11/xlibimage.c reimplements the small part of the wraster image API the backend actually uses (RContext, RGetClosestXColor, and the RXImage create/get/put/destroy calls) on plain Xlib. It does not use MIT-SHM, and non-TrueColor visuals are resolved with XAllocColor. The struct and function names match wraster.h, so the call sites are unchanged and the graphics backend picks the implementation through a single guard in XGPrivate.h.

The default build (USE_WRASTER=0) compiles xlibimage.c in place of the bundled wraster sources. Configuring with --enable-wraster (USE_WRASTER=1) keeps the previous behaviour: the wraster sources are left untouched and compile exactly as before, so the two builds can be compared directly. This keeps wraster available rather than dropping it.

I checked that cairo, xlib and art build under both settings. For the xlib backend I compared the pixels read back through GSReadRect under each build and they are identical.

Relates to #98.

@DTW-Thalion
DTW-Thalion marked this pull request as ready for review July 27, 2026 11:40
@DTW-Thalion
DTW-Thalion requested a review from fredkiefer as a code owner July 27, 2026 11:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant