freenode/#clim - IRC Chatlog
Search
2:41:06
loke
I have to admit, the reason for that is that I've been playing a viedeo game that I don't even like very much
2:52:30
loke
It's free on PSN, and I started playing it. The combat is boring and repetetive (both on-foot and the car battles)
2:53:26
loke
Even though they killed Joker in the last game, they drag him out as a figment of batman's imagination (he's slowly becoming Joker) becuase it's apaprently impossible to make a batman story without Joker?
2:53:58
ck_
like it is impossible to make a Star Wars story without Rebels and and Empire ;) I understand what you mean
2:54:43
loke
Well... There are a lot of good villains, and the main vaillain of this game is Scarecrow, who is doing a good job. I guess that's one of the reasons I'm still playing it
2:55:50
loke
Oh, and Harley Quinn looks weird (from a 3D model perspective), is acted badly, and behaves like a tantrum child.
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