freenode/#clim - IRC Chatlog
Search
7:28:33
scymtym
jackdaniel: i changed the medium gcs to render into a single pixmap for the whole sheet hierarchy. the port event loop executes a buffer swap protocol every time a frame should be presented (e.g. up to 30 times a second). that protocol consists in sending the top-level sheet an event with a condition variable in it. when the sheet's thread processes the event, it notifies the port thread and waits. when notified, the port thread copies
7:28:33
scymtym
the sheet's pixmap into the X window and notifies the sheet's thread when done. with that the frame is done and both threads resume normal event processing
7:50:56
|3b|
jackdaniel: it's currently about 3 or 4 entries from the top of my project stack, so not much progress at the moment
7:51:26
|3b|
ACTION will work on it more when i get back to implementing the things it would use, which are a level or 2 above it on the stack
8:45:40
jackdaniel
beach: standard leaves the decision to the backend, so our "core" code must assume that mirror mappings may be arbitrary
8:46:20
jackdaniel
currently clx's frame manager is capable of having a single mirror for top-level sheet, full mirroring of each sheet in a frame and a random mirroring (with top level being mirrored)
8:48:33
jackdaniel
scymtym: I wonder if we could simplify it by utilising only the medium's protocol (most notably 15.6 Buffering the output and medium-finish-output)
8:49:48
jackdaniel
in this case the medium-drawable would be a shared pixmap between all mediums with the same top-level mirror
8:50:48
jackdaniel
currently I'm documenting medium protocol (from a backend writer perspective), I hope to make a PR next week given we're done with distribute-event, click to focus and drag-and-drop pull requests
8:51:52
jackdaniel
(n.b: additional perk of such approach would be possibility to turn on / off double buffering with (setf medium-buffering-output-p) and/or with-output-buffered, also imo this is far more intuitive than juggling with events
9:13:30
beach
jackdaniel: Yes, sure. I am not advocating the removal of the code that can handle mirrored sheets.
9:46:15
scymtym
jackdaniel: in the approach i outlined, client code is not concerned with additional events. the port uses the event to briefly suspend the application thread while it displays the "frame"
9:47:54
scymtym
the medium-level seems to be too fine-grained to control the presentation of consistent "frames". but consistent frames are needed for avoiding flickering
9:48:41
scymtym
loke: that's a recent regression, i have a fix in https://github.com/McCLIM/McCLIM/pull/841
9:50:17
loke
To reduce flickering, isn't the best solution to do all rendering to an Xrender buffer and simply copy that buffer to the screen when a refresh event is received?
9:50:46
loke
(the Xrender buffer cna be backed by a pixmap, so legacy Xlib fcalls can actually still be used)
9:54:18
scymtym
loke: i did the off-screen buffer part (i.e. a pixmap - whether you draw with render or legacy doesn't matter for that afaict). but blitting after every event is too much, i think. thus the idea of synchronizing and blitting at a given framerate (skipping the update if there were no changes)
10:01:11
beach
loke: You also need to update the screen as a result of some action on the part of the application.
10:06:16
jackdaniel
scymtym: I imagine that the frame top-level loop calls medium-finish-output on a medium associated with the a top-level-sheet upon iteration. I will try to explore this approach further while working on the documentation I've mentioned
10:19:30
loke
beach: Yes, that is true. I'd argue that the best way to do that, however, is to inject a synthetic ExposeEvent when you want to display.
10:21:23
jackdaniel
output is done in the frame's thread, it would be a waste to queue the event to dequeue it in the same thread
10:22:04
beach
I think that's the problem scymtym is trying to solve. If it is done for each drawing operation, it's too frequent, and there are operations that require the display to be refreshed before there is any return to the top level.
10:27:12
scymtym
what beach says. the main problem is that McCLIM can't know at which point in time the content produced by the application thread is consistent. but suspending the application thread after it has finished processed a batch of events and before it starts processing the next batch has a good chance of capturing a consistent state of the content
10:29:28
scymtym
think of a POINTER-MOTION-EVENT leaving one push button gadget and entering another. there will be multiple drawing operations in response to deactivating the first button and activating the second one. putting the content on screen at some point between operations will result in inconsistencies (e.g. both button appearing active)
10:30:18
scymtym
but it was just an experiment. i'm not proposing to change McCLIM's architecture tomorrow or something
11:53:56
scymtym
having a concept of a "frame" may also be a good place to hang animations off of: https://techfak.de/~jmoringe/mcclim-double-buffering-2.ogv
14:40:21
beach
I wonder whether what you did is similar to what gilberth experimented with and for which he had a demo.
14:48:29
antoszka
Strange, wget works via terminal. I get 404 over browser. Probably because browser switches to HTTPS and it's not present in the SSL vhost.
14:49:14
antoszka
here's a https-browser-compatible copy: https://antoszka.pl/tmp/e5c65X3f2858693b441fbfcb889fa702afX40186.mp4
14:51:20
scymtym
that's one implementation strategy. but i don't think it is enough on its own for reasons described above
14:53:24
beach
scymtym: I am convinced that for animations (which need a fixed, stable frame rate) your solution seems more appropriate.
15:01:32
scymtym
beach: yeah, there are many technicalities, of course, but basing animations on some kind of frame timing seems good
15:02:42
jackdaniel
so this comparison cheats (if only a little), xquartz has proven to have performance issues which are not present on "normal" x11 server
15:04:13
scymtym
jackdaniel: i'm still not done because i found more enter/exit corner cases. it has become pretty hard to get unmatched pairs by now
15:05:15
jackdaniel
regarding animations, I was thinking more about something like an "animation processor" to which sheets subscribe declaring the framerate. this "processor" emits an event for them. this way we could have many animations with different fps (i.e something what divides 60)
15:05:25
scymtym
one issue is that EVENT-SHEET can be different from the sheet obtained by looking at REGION-CONTAINS-POSITION-P
15:07:10
scymtym
i did something similar but with the port as the animation processor since animating fewer times or more times than once per frame is not ideal
15:07:10
jackdaniel
I would rather depend on frames as little as possible with these things (in favor of having sheet / medium protocols) for better modularity
15:07:53
scymtym
oh sorry, "frame" = one consistent unit of content that should be displayed on the monitor in this context
15:10:15
jackdaniel
i.e if you have only 15fps animations then sure, why not. if you have 15fps and 30fps, then frame rate would be 30fps, and if you have animation declaring 60fps, then there you go, blazing fast tearing in CLIM :-)
15:10:38
|3b|
the timing in that video is suspiciously close to 1 line per frame, which doesn't exactly sound like a performance problem
15:11:20
scymtym
i believe the port should decide. consider broadway, it may limit updates to 10 fps for bandwidth reasons. a different port may know the refresh rate of your monitor, going above or below that for animations seems suboptimal
15:13:14
jackdaniel
maybe so (buffer-swap-wise), but if we are going to provide animation api, then events should be generated per request
15:16:03
scymtym
in many designs, animations receive tick events with elapsed time in the event and decide whether and what to repaint based on that