freenode/#clim - IRC Chatlog
Search
6:14:27
ck_
can anybody tell me where in the code an image-pattern is actually drawn into the frame buffer? I feel like a blind person with a divining rod stumbling around and tripping over the indirections
7:10:42
loke
ck_: Oh, right. JD redesigned some of this (which is why the fast image transformations were disabled)
7:11:45
loke
That code calls WITH-CLX-GRAPHICS before drawing the rectangle. THat sets the pattern which is used to draw. The pattern is initialised here:
7:43:18
jackdaniel
n.b fast image transformations will be introduced when we start storing transformations with output records (instead of recording transformed things)
8:29:01
jackdaniel
what loke did is a good proof of concept but it ditched CLIM protocols to make it "work", that's why I've disabled it
11:37:02
ck_
... or I won't. Fooled by function names, again: %collapse-pattern works ok for expanding scales -- the fault is somewhere else
11:37:23
ck_
I recall seeing a comment about a maximal size somwhere in the CLX files, 2048^2 maybe?
11:38:22
ck_
yeah, there it is. no warnings or anything, but xlib:put-image is not called for larger sizes.
11:49:37
jackdaniel
please make pull request which signals a continuable error (where continuation is not to display the image)
11:54:01
ck_
just kidding. I'll take a look around instead though, surely there's a better way? I don't even know what the deal with that size limitation is
11:56:09
ck_
I believe you and pass on the explanation. But I do have a question: wouldn't it be possible to draw larger images in parts?
11:58:06
jackdaniel
X11 protocol defines maximum request size (I think that size is encoded in 16bit field? don't remember)
11:59:44
jackdaniel
and that's the limit of how much you can send over x11 protocol. what you *can* do is to call separate put-image on parts of your image
12:00:14
jackdaniel
so i.e you split your image in four, then you send each part scanline-by-scanline (and you fix the coordinates so they are aligned)
12:20:08
jackdaniel
if fix is not something approachable then putting there warning and rendering ugly lambda is good enough for me
12:26:46
jackdaniel
here is a crib of what I'll be talking about tomorrow: http://hellsgate.pl/files/aa68c0b0-presentation.pdf subject of change
12:30:11
ck_
jackdaniel: sorry, I meant to paste the pull request link right after, but pushed the wrong magit buttons so I had to clean up first
12:42:23
ck_
it was a shot-from-the-hip commit to see whether this approach is maybe fundamentally stupid from a different perspective
12:46:51
ck_
maybe, but your comments are still valid, it's just that an overarching ruling might make the whole thing obsolete
12:47:54
ck_
Well, we can have a discussion on the github page, that's what it is there for, right? Kicking the ball around a bit
13:23:57
scymtym
that seems confusing. if 2048 is the maximum request size, why compare the image width and height to it? maybe +X11-IMAGE-DIMENSION-LIMIT+ (taking inspiration from ARRAY-DIMENSION-LIMIT)?
13:27:38
ck_
Yeah sorry, I got the names mixed up there, jd's name for the reason was still reverberating
13:30:49
ck_
so yeah, the maximum request length is a "CARD16", that's their name for a 16 bit unsigned int. Length of what exactly though? A square image just below the size that got rejected by the current code is already 2^22 pixels
13:32:27
scymtym
are there multiple restrictions in play? i don't know much about the X11 protocol either
13:34:30
ck_
Maybe I'll research this another time, for now I have more pressing matters to attend to ... lunch
13:36:22
jackdaniel
it could be that I've mixed up things and 2048 triggers another issue (not the "too big of a request" one)
13:36:40
jackdaniel
and this issue could have been present only on some X11 builds because i.e it was the xserver bug
13:37:54
ck_
I didn't try removing the safeguard, am afraid of graphics glitches and trusted the previous developer that visited the code
13:49:43
scymtym
ck_: now that i look at the code again, one PUT-IMAGE call (the one in COMPUTE-RGB-MASK) has arguments :bitmap-p nil which the other lacks. you probably have to preserve this
13:53:59
ck_
scymtym: ... or maybe not, if you take a look at the function. There's no difference between the calls actually.
13:54:24
scymtym
also, am i reading this wrong or does clx already have code for splitting putimage into multiple requests? taking into account DISPLAY-MAX-REQUEST-LENGTH and everything
13:55:15
jackdaniel
I've mentioned that. This splitting doesn't work when a single scanline does not fit in the max request length