libera/#clim - IRC Chatlog
Search
9:25:29
jackdaniel
slightly off topic, but I've been thinking for a while now about virtual file system inside the lisp runtime, then we could use all file functions on in-memory data. I hope that I'll have time to make it work in ecl some day
9:34:35
beach
Clouseau scrolling is pretty slow though. Not sure whether that's specific to Clouseau or not.
9:39:27
beach
What you just said makes me think it is the solution to several problems, including the slowness of displaying all those lines.
9:39:28
jackdaniel
the apparent slowness is also a result (perhaps a regression) of something I've changed some time ago - we force the sheet repaint when the geometry changes (not only dispatch the repaint)
9:40:20
jackdaniel
(consider i.e an interactive operation in the listener (ql:quickload 'whatever) - it would be desired to see the output not only after the system is fully loaded)
9:51:16
jackdaniel
n.b regarding double buffering, the macro with-output-buffered is part of the specification (not that it is implemented)
9:52:20
jackdaniel
right. I have a prototype implementation in one of my branches, but I'm not sure if that approach is the right thing
9:52:42
jackdaniel
also using such macro would be slightly with odds with the fixed framerate approach
9:53:27
jackdaniel
but leaving the programmer with control when to "flush" their complicated drawing make sense to, even if not by default
9:53:52
jackdaniel
i.e (with-output-buffered (medium) (some-lenghy-operation)) would give them a separate pixmap to draw on
10:26:30
john-a-carroll
jackdaniel: was the display issue meant to go away with (setq clim:*default-server-path* '(:clx-fb :mirroring :single)) ?
10:26:41
john-a-carroll
I'm running macOS / XQuartz 2.8.1 and with that *default-server-path* I still get glitches: http://users.sussex.ac.uk/~johnca/scroll-test-it.webm
10:27:29
jackdaniel
it went away for beach, as I've said I don't observe on my desktop the problem. I'm considering starting it in vm to reproduce and investigate
10:30:32
john-a-carroll
Hmm. Possibly it's timing-related because for me the glitches appear in different places each time
10:34:34
john-a-carroll
For me, it looks a bit like random-nick's https://0x0.st/-xP5.webm but not quite as bad
10:41:04
jackdaniel
speaking of repainting, one issue with this is the fact that drei confuses redisplay and repaint (basically having a single implementation for both) and its functions are not reentrant
10:41:34
jackdaniel
so when you call repaint from inside display function on a drei pane you may have very interesting results, including error buffer popping up
10:47:01
jackdaniel
that's fine; but I'd also like to have a solid implementation of a plain text-field and text-editor panes in core
10:47:28
jackdaniel
(by plain I don't mean simplistic, I mean - with narrowed scope of functionality to bare minimum)
13:38:12
random-nick
jackdaniel: I tested in a fresh archlinux vm, and the bug does seem to be dependent on the desktop environment
13:38:36
random-nick
it appears on kde and gnome on wayland (where mcclim is presumably running via xwayland)
13:39:12
random-nick
as for xfce4, it appears when display compositing is on but disappears when display compositing is off
13:40:18
random-nick
so it seems to be dependent on the window manager (or more likely, the window manager's compositor)
13:40:24
jackdaniel
I have xfce4 with compositing (but no wayland) and no visible defect; thanks for the hint
13:49:25
random-nick
jackdaniel: I just rebooted the vm with software graphics instead of paravirtualised graphics and the bug disappeared under xfce4
13:51:46
jackdaniel
i.e when I log in I can choose between various options, like xfce4, gnome classic, gnome wayland
13:54:38
jackdaniel
well, xquartz is something I can't check because apple seems to be reluctant to make their software available on "normal" virtual machines
13:56:36
jackdaniel
but then, it is not my fault I can't improve their customers experience for free ,-)
14:00:14
random-nick
I just tried kde on my host system (I have amd graphics) and the bug does appear
14:10:00
random-nick
forgot to mention that the single mirror backend doesn't have the artifacts for me
14:11:42
jackdaniel
we may always pretend that there is no bug and take delight in implementing bezigon inclusion point test
14:14:00
beach
Maybe the single-mirror backend should be the default. People who write their own mirrored sheets may have to work a little bit harder then, but it would make life easier for most of us.
14:15:44
jackdaniel
I think that having single mirror by default in clx backend is fine. what's more, that does not stand in opposition to having inside sheets with their own mirror even if we default to that
14:17:21
jackdaniel
a correct implementation of the specification implies, that mirrored and unmirrored sheets may be interwened in the hierarchy
14:17:56
jackdaniel
when :mirroring :full is specified for the clx default port it only means, that the frame manager adds a mirrored-sheet-mixin to each created pane
14:18:20
jackdaniel
if you specify :mirroring :single, the frame manager won't do that, but if the pane is specified itself to have a mirror then it will have one
14:18:41
jackdaniel
what's more, for testing purposes I've also implemented a variant :mirroring :random
14:19:08
jackdaniel
and it also seems to work rather fine (although there are some corner cases that are not very gracefully handled)
14:32:41
jackdaniel
perhaps this may be because my machine is reasonably fast and something "catches up" to some other concurrent process
19:25:36
random-nick
so I looked into that issue again and found something confusing: when I hover my cursor over the window manager's close button, the bugged text disappears, displaying the scrolled sheet how it's supposed to look
19:27:26
random-nick
I'm not really familiar with mcclim's implementation and the x11 protocol, but I found a clim-clx::event-handler function and traced it, and seemingly got the windowing system events printed out, but when I hovered over the close button no trace was printed
20:51:45
jackdaniel
perhaps clim should call display-force-output at some point and it doesn't? or something in this spirit
21:04:40
random-nick
display-finish-output seems to be called constantly, even when I move the cursor while on the window
21:05:20
random-nick
assuming display-finish-output is like finish-output in that it doesn't matter how much after the output you call it