freenode/#clim - IRC Chatlog
Search
10:49:08
jackdaniel
cl-dejavu system is now available on Quicklisp, so we should be able to just put a dependency from McCLIM and get rid of hardcoded dejavu paths
11:52:13
jackdaniel
clipping with xrender: https://files.mastodon.social/media_attachments/files/105/621/874/626/961/414/original/13f6448e567b2124.png
15:03:51
ck_
I was sick but can now try to attempt working on those open compose-in implementations. Is there a test or demo for that already? Otherwise I think creating one is a good first step
15:05:21
jackdaniel
you may reduce things when due, but do not be tempted to i.e manually blend inks
15:06:36
jackdaniel
in principle we want to be able to take each ink in the "composition" and do the real composition i.e in a hardware-accelerated backend's method
15:16:53
jackdaniel
now, I have found an interesting bug: changing the medium transformation does not invalidate the clipping region (but it should!)
15:18:31
jackdaniel
why? because (setf medium-clipping-region) in fact stores a transformed region and the reader untransforms it
15:18:58
jackdaniel
as o fwhy we store in sheet coordinates is a mystery to me, but I'm not going to touch that for now
15:24:36
ck_
I'll be ok, thanks. By test or demo I meant a matrix with a set of ink/medium combinations, so we have something to look at. Is this a bad idea? Please take into account that I'm only just trying to get familiar with the terminology of the spec
18:20:39
scymtym
jackdaniel: the "patterns and designs" demo says if the y axis is flipped, DRAW-PATTERN* should draw the pattern within the flipped region (but without flipping the pattern itself, of course). do you know where the requirement to adjust the pattern position comes from?
20:41:15
jackdaniel
scymtym: my understanding of the spec is that draw-pattern* draws the pattern as a rectilinear rectangle filled with the pattern. since pattern is not a subject of the transformation, then it should always start at the top-left corner
20:46:26
scymtym
that would have to be based on the bounding box of the pattern since the shape of the pattern itself doesn't have to be an axis-aligned rectangle, right?
20:50:06
jackdaniel
afair if you do not call explicitly transform-region the pattern, then it always is axis-aligned rectangle; if you call transform-region, then hmm, I would need to think
21:13:37
jackdaniel
OK, so as I understand it, transform-region on the pattern transforms it (say, into a square rotated by pi/4)
21:15:07
jackdaniel
the medium transformation affects only the position of the transformed pattern (as in - we take into account only the translation)
21:16:22
jackdaniel
and to do that, we indeed take the bounding rectangle of the transformed rectangle (looking at the code)