freenode/#clim - IRC Chatlog
Search
10:21:03
ck_
jackdaniel: re/people look for the definition: I agree of course, but I didn't remove the defvar/defparameter definitions. the special declaimations I put in because those forms occur at a later time in the asdf order; anybody M-.'ing will arrive at that form
10:21:36
jackdaniel
I'd rather move defvars earlier than declare them beforehand but this is fine too I suppose
10:23:43
scymtym
ck_: sorry for the miscommunication. i thought since you were taking charge, you could incorporate my change into your pull request
12:03:09
scymtym
jackdaniel: thanks. i haven't thought about it. i guess, as long as credit is given and the content is not framed inappropriately, i have no objections
12:05:21
scymtym
jackdaniel: now i'm curious, though. would you provide a link to the social media post?
12:08:58
scymtym
the protocol and client side are already a little different from the original GTK version, but your description is still accurate
12:14:33
no-defun-allowed
Whoa, that was quick...weren't you just drawing boxes not long ago, scymtym?
12:17:08
scymtym
no-defun-allowed: yes. check https://techfak.de/~jmoringe/mcclim-broadway-{1,2,3,4,5,6}.ogv for progress over time. however, those don't show the whole story, since you can't see the protocol spoken between client and server
12:22:27
no-defun-allowed
It still seems magical that someone could write a backend for a graphics toolkit in less than a month.
12:24:14
scymtym
the protocol or protocols rather are one of the harder parts. especially since GTK changed their approach (and protocol) entirely at one point and still called it "broadway 2.0"
12:24:59
jackdaniel
no-defun-allowed: CLIM's protocol complexity is overestimated while an effort to bring a prototype to a usable shape is usually underestimated
12:26:21
scymtym
regarding implementation speed: keep in mind that i didn't have to write the javascript client from scratch - i just adapted it a bit. also, the backend uses off-screen rendering, then transfers pixels in a smart way, so i didn't have to implement rendering, "just" what amounts to a streaming video codec
12:27:53
scymtym
jackdaniel is totally right. if what i have now is one unit of work, getting to a usable backend is probably five or more units of work
12:41:59
jackdaniel
we could create a medium-crutches-mixin which draws everything using medium-draw-point* method unless specialized further :-)
12:42:55
scymtym
i think i made a significant improvement to the render backend's speed, but i haven't benchmarked it
12:43:19
ck_
wow, I think that working on that issue has left some scars. I just caught medium-draw-something* and my pulse went up
12:46:54
scymtym
not recompute the foreground "ink" unnecessarily: https://github.com/scymtym/McCLIM/commit/7ec10701c86c8c7a75b10f0806106b71eca526ab
12:48:10
jackdaniel
my main focus last time I've worked on this code was to reduce insane macrology used there without caring much about performance at the moment
12:49:02
scymtym
i'm prepared to throw that work away. i just needed the thing to be faster so i could work properly on the backend
12:51:12
jackdaniel
just saying that I might have degraded performance significantly while removing #1=(writing-code . #1#) macros
12:57:56
jackdaniel
scymtym: 1ae81284184dd6d5eabd53b2d6ede6493fcce2c5 (branch origin/medium-transformation-fixes -> origin/master)
12:59:12
jackdaniel
ck_: n.b this very merge impacted the osx performance, namely implementing transformed-patterns
15:36:19
ck_
hmm, M-x whitespace-cleanup also converted the tabs. I guess someone will complain about that -- better revert that part of the changes.
15:43:58
beach
My personal thinking is that I will (over time) convert all my code so that there are no more TABs in it. And I set the Emacs flag that makes TABs no longer used, so all new source code I write is TAB free.
15:55:32
jackdaniel
I know it makes git history somewhat polluted otoh our "official policy" is to not use tabs
19:35:14
ck_
I think the xlib macro that was supposed to be mentioned was WITH-STATE -- if you wrap code manipulating a drawable in it, there's this alist *window-attributes* that caches the value for a whole bunch of things.
20:05:45
scymtym
|3b|: i think it is similar to the X root window, i.e. the parent of top-level sheets. i have seen the hierarchy visualized as port -> graft -> top-level-sheet -> other-sheets
20:05:47
|3b|
i guess mostly just an CLIM thing, not a backend thing. should it map to entire desktop or to a specific monitor?
20:10:43
|3b|
i guess theoretically it should map to monitor since it has physical dimensions, but in practice probably to entire desktop, since i don't see anything to specify monitors, or handle windows spanning them
20:13:08
scymtym
i don't know whether that works in practice with frame sheets spanning multiple grafts and whatnot
20:35:01
jackdaniel
but in principle they should provide a transformation from the sheet coordinates to the native coordinates
20:36:33
jackdaniel
and transformation associated with that graft transform coordinates to whatever is assumed by medium as input
20:37:19
jackdaniel
in practice though in McCLIM grafts are only used for probing screen properties (i.e pixels per mm)
20:57:56
|3b|
jackdaniel: how should "screen properties" be interpreted with multiple monitors on 1 port?
21:00:56
jackdaniel
that's a hard one. I did think about that when I was looking for a consistent model with multiple monitors with different dpi (I want to make dp a default native unit)
21:01:58
jackdaniel
one could stipulate, that each screen has a separate graft, but what about sheets which are moved between screens (and i.e part is on one and the other is on another)
21:03:23
jackdaniel
you would have to duplicate frame panes (as in: regenerate them) with different pane and render frame twice with a clipping region until we move onto one
21:03:57
jackdaniel
then you'd have a funny effect of the same window on different monitors with the same physical size but with a different resolution
21:05:19
|3b|
not sure 2 os-level windows would work well, would be hard to keep them synchronized, and borders at screen edge would be odd, + extra decoractions etc
21:06:29
jackdaniel
either way I did not come with anything yet with this regard except: take the first screen and pretend all have the same properties
21:07:39
|3b|
so for graft size in MM/inches, calculate PPI of primary monitor and then multiply by total size of desktop?
21:10:56
jackdaniel
currently McCLIM assumes pixels, so it doesn't matter (you are not interested in mm/inches)
21:11:07
jackdaniel
when we switch to dp (density independent pixels) then it will make a difference
21:11:55
jackdaniel
and given how fast things move in open source world it will assume pixels for quite a while ,)