Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

put-image fails when display's pixmaps have depth different than their bits-per-pixel value #77

Open
TeMPOraL opened this issue Jul 5, 2017 · 1 comment
Labels

Comments

@TeMPOraL
Copy link

TeMPOraL commented Jul 5, 2017

During work on a CLIM implementation I encountered the following problem with xlib: doing a PUT-IMAGE on an IMAGE-Z fails with a condition of: "The bits-per-pixel of the image #<XLIB:IMAGE-Z 12x12x24> does not match any server pixmap format.".

My current theory is that the error happens because, within the code of PUT-IMAGE, the pixmap-format found by depth (find depth (display-pixmap-formats display) :key #'pixmap-format-depth) is one with depth 24 and bpp of 32, and the latter is not equal to the expected 24 of (image-z-bits-per-pixel image).

There's a comment in PUT-IMAGE that seems relevant:

;; We could try to use the "/* XXX slow, but works */"
;; code in XPutImage from X11R4 here.  However, that
;; would require considerable support code
;; (see XImUtil.c, etc).

I wonder what exactly is the work needed here and how much effort would it take to make PUT-IMAGE work with this case.


Details

The issue was found on recent SBCL versions running on Ubuntu 16.04 (native) and on Ubuntu 14.04 (in VM), running both stock window manager and StumpWM.

Relevant object details:

  • Call from condition backtrace:
(XLIB:PUT-IMAGE #<XLIB:PIXMAP :0 2600025> #<XLIB:GCONTEXT :0 39845924> #<XLIB:IMAGE-Z 12x12x24> :SRC-X 0 :SRC-Y 0 :X 0 :Y 0 :WIDTH NIL :HEIGHT NIL :BITMAP-P NIL)
  • The IMAGE-Z object:
#<XLIB:IMAGE-Z {10082D1AD3}>
--------------------
The object is a STRUCTURE-OBJECT of type XLIB:IMAGE-Z.
WIDTH: 12
HEIGHT: 12
DEPTH: 24
PLIST: NIL
BITS-PER-PIXEL: 24
PIXARRAY: #2A((16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215 16777215) ..)
  • The contents of the PIXMAP-FORMATS slot from the DISPLAY object referenced by PIXMAP object found in the stack trace:
A proper list:
0: #<XLIB:PIXMAP-FORMAT depth 1 bits-per-pixel 1 scanline-pad 32>
1: #<XLIB:PIXMAP-FORMAT depth 4 bits-per-pixel 8 scanline-pad 32>
2: #<XLIB:PIXMAP-FORMAT depth 8 bits-per-pixel 8 scanline-pad 32>
3: #<XLIB:PIXMAP-FORMAT depth 15 bits-per-pixel 16 scanline-pad 32>
4: #<XLIB:PIXMAP-FORMAT depth 16 bits-per-pixel 16 scanline-pad 32>
5: #<XLIB:PIXMAP-FORMAT depth 24 bits-per-pixel 32 scanline-pad 32>
6: #<XLIB:PIXMAP-FORMAT depth 32 bits-per-pixel 32 scanline-pad 32>

I might be able to provide a simple reproducible test case after 2017-07-10. In the meantime, see this for more context.

@dkochmanski dkochmanski added the bug label Feb 1, 2018
@JMC-design
Copy link
Contributor

This is not a bug, this works exactly as the spec requires.
It is the users responsibility to create images appropriate for the drawable to put to.
The fix is to change your code to generate (array '(unsigned-byte 32) (* *)). Instead of (unsigned-byte 24)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants