libera/#clim - IRC Chatlog
Search
7:06:35
jackdaniel
defaultxr: that's how this could be approached: https://plaster.tymoon.eu/view/3123#3123
7:07:04
jackdaniel
notice, that you need to provide /whole/ dimensions when constructing the record, so scroll bars know how much space your pane occupies
7:08:56
jackdaniel
this perhaps could be polished into a demo, but oh well, having only 10 fingers is certainly a limiting factor ,)
7:10:32
jackdaniel
n.b the fact that I had to use pane-viewport-region instead of supplied region to replay-output-record is a hint, that the supplied region is too big
7:12:29
jackdaniel
it is surprising, because we do compute the intersection with parents in repaint-sheet
7:51:50
jackdaniel
this is interesting read on UNIX trivia: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html (i.e why there are /bin and /usr/bin)
14:34:23
scymtym
this approach of using an application pane, a scroller, PANE-VIEWPORT-REGION and output record tricks can actually go pretty far: https://techfak.de/~jmoringe/mcclim-double-buffering-7.ogv
14:39:44
beach
Wow, it looks very sophisticated. But I am not sure what I am seeing in terms of CLIM.
14:46:27
scymtym
basically just an application pane with a large sheet region in a scroller. this was meant as an example of letting the user scroll around (by steering the "rocket" in this case) and only drawing things that are actually visible
15:00:10
jackdaniel
scymtym: do you use there a double buffering technique you've mentioned the other day?
15:02:18
scymtym
jackdaniel: not sure about "the other day", but yes, this uses the double buffering approach i have been working on for a long time
15:04:09
scymtym
(the screen capture framerate is apparently a little low. the actual window looks smoother than the video)
15:04:15
jackdaniel
a few months back you've said on this channel that you've finally "got it right" or something in this spirit
15:07:13
scymtym
the branch is called clx-double-buffering, but it is neither very CLX-specific nor is it technically double-buffering, so i don't know about that as a name ;)
15:10:14
scymtym
it is rendering to a single off-screen buffer, not rotating the roles of two buffers between displayed buffer and off-screen buffer. that's why it is technically not double buffering
15:11:10
scymtym
accordingly, "flipping buffers" becomes suspending the drawer and copying the off-screen content to the display
15:11:53
scymtym
i think actual double buffering would work just as well but i didn't see the benefit in this particular case
15:11:57
jackdaniel
that's what the clx-fb does (bar copying to the intermediate array, but that intermediate operation is redundnat), isn't it?
15:13:07
scymtym
clx-fb is a bit similar but it goes client-side off-screen buffer -> server-side off-screen buffer -> display, if i recall correctly. clx-fb also does the synchronization very differently
15:13:10
jackdaniel
I'm experimenting right now with three buffers, to allow concurrent drawing and flushing to the drawable
15:14:38
scymtym
right, clx-fb is different because drawing operations affect a client-side buffer, while in clx drawing operations already affect a server-side buffer
15:24:09
scymtym
doesn't seem to matter much as far as i can tell. i guess because everything happens on the server side, blitting some pixmap to the screen is fast
15:38:44
jackdaniel
scymtym: also, when do you synchronize? after arbitrary delay (i.e 1/60s), or when the frame content is ready?
15:41:31
scymtym
that part is pretty complicated. i have made a few diagrams to go along with the code to describe the dynamic view