freenode/#clim - IRC Chatlog
Search
10:27:02
jackdaniel
it is an indexed-pattern 25x25 with two inks being rectangular patterns of size 25x25 which have as inks patterns 20x20
10:29:43
loke
jackdaniel: xrender does, and I already have a prototype implementation of xrender for lines and plygons.
10:29:47
jackdaniel
but when I'm done with adjusting code to that, I want to provide xrender alternative, yes
10:30:15
jackdaniel
but this has to work for fallback. I'm not brave enough to abandon x servers without xrender extension
10:31:16
loke
also, you can't even draw truetype text without it (both freetype and truetype implementation suse xrender to draw the glyphs)
10:32:40
jackdaniel
I'm not saying we won't abandon it in the future, I'm just saying I'm not ready to do it now
10:34:50
jackdaniel
and all should work without clx (except maybe some recent additions, but in that case it is a bug that such thing doesn't have a fallback)
10:36:17
loke
jackdaniel: fair enough, but I tried it some time ago and all I got was the default "FIXED" font for everything.
10:39:40
jackdaniel
is it a reasonable limitation to forbid using indirect inks in pattern? when we have such ink it is impossible to collapse it (each change of indirect-ink value will invalidate rgba array)
10:41:14
jackdaniel
so if you change medium foreground color and you have something drawin with +foreground-ink+, then repaint / replay will fix that automagically
10:42:28
loke
So you're saying that if you create an output record containing such ink, and then change the enclosing ink and redraw the output record, then the output record's ink would change correspondingly?
10:43:15
loke
I see... WOuldn't it make sense that the effective ink used would be "locked in" when the output record is created?
10:53:07
jackdaniel
verifying on clim side if x/y didn't change and setfing accordingly is fine by me
10:53:33
loke
jackdaniel: I haven't experimented with any potential solutions yet, because I'm not entirely sure of the cirumstances under which you had the window walking beahviour
10:56:14
loke
I think I see how that could happen... It'd change the desired size, which results in a call to set-mirror-transformation, which then sets the x/y coordinates to the old values, resulting in that behaviour
10:56:45
loke
OK, and just changing the x/y to 0/0 that we discssed a couple of days ago should revert back to that old behaviour?
13:48:21
loke
I'm wondering if it is because I have a compositing window manager. If you do, you never get window reconfigure events when moving a window anyway...
15:59:28
loke
jackdaniel: Since we can't reproduce it, how about reinstating the 0/0, and if we see it happen again I now know how to fix it properly.
17:44:25
jackdaniel
slyrus: is it possible for you to use old png load code on clisp (instead of pngload library)?
17:44:42
jackdaniel
it seems that pngload depends on static-vectors which deliberely states, that it won't support clisp
20:24:19
slyrus1
it would be nice if pngload worked on clisp but I don't really want to go back to png-read
20:25:19
slyrus1
jackdaniel, loke: can you take a look at https://github.com/slyrus/McCLIM/tree/scigraph-vertical-text
20:25:55
slyrus1
some of the changes are independent of the vertical text, and could be broken out -- particularly the removal of clim-postscript::*transformation*
20:36:30
slyrus1
it would be nice if we could make it through the graphics test in both PS and PDF modes