freenode/#clim - IRC Chatlog
Search
23:10:53
slyrus
Ok, I'm pretty sure an :after method on handle-event for top-level-sheet-pane is the wrong way to go about redisplaying on resize, but it's the only method I've found that comes close to working.
2:02:51
djeis[m]
jackdaniel: Mostly just noted (as you did) that UI bottlenecks are usually elsewhere than dispatch with a few additional examples. Also made the point (from experience) that inlining generic functions only really helps in fairly carefully controlled circumstances.
2:03:43
djeis[m]
Unless there's enough info to statically optimize away parts of the dispatch table all inlining will do is kill your I-cache.
5:40:26
slyrus
beach: do you know if there is a sane way to trigger a redisplay while resizing a window?
6:06:55
beach
It is not a good idea to trigger a redisplay in that situation. And by "redisplay" I mean what the spec says, namely that it re-creates the output records from scratch, from some internal data structure.
6:07:59
beach
So what is needed is some kind of pane that can take existing output records and replay them differently.
6:09:22
slyrus
Why is it bad to re-create the output records from scratch? I could see that the latter approach might be _better_ but the former doesn't necessarily seem bad.
6:55:50
loke``
beach: I'm not sure that would work. The lines are broken when word wrap is appled and split into multiple output records, one per line.
6:59:00
beach
slyrus: The redisplay function is synchronized with the command loop, not the event loop.
7:00:00
loke``
beach: but you don't want to reflow after every resize event. When resizing you get hundreds of resize events in quick succession.
7:08:33
slyrus
hmm... two separate issues here. beach's command loop vs event loop issue and loke's hundreds of resize event issue.
7:09:18
beach
The latter is probably not to hard to fix. Just check whether the next event is also a resize.
7:09:24
slyrus
Before tackling these, I should mention that i have an existence proof of at least a hackish way to make things sort of work.
7:10:18
beach
slyrus: For a particular application, you can do what you want of course, but it can't be part of the default way to invoke redisplay when the window is resized.
7:11:12
slyrus
Ok, it doesn't have to be the default, but it seems like it should be a reasonable thing for an application to do.
7:12:39
beach
The reasonable thing to do would be to provide pane types and output-record types that can be replayed differently when the window is resized.
7:13:54
slyrus
Sometimes you need to repeat yourself before it manages to make it through my thick skull
7:15:44
loke``
beach: Buf if the output-record replays differently, the size of said output-record will also change. That needs to trigger an update of subsequent output-recordss as well (the next one may need to move so it stays at the same point relative to the previous oen)
7:16:01
slyrus
beach: And are you implying that events don't have a way to influence the command loop?
7:16:12
loke``
I don't think there is a clean way to simply resize an output record and having everything else do the "right" thing.
7:22:17
beach
slyrus: Well, you can do some kludge of course, but normally, the event loop is at a lower level than the command loop.
7:31:01
slyrus
beach, I'm not saying your approach couldn't work, but it seems to me that the figure-out-how-to-redisplay-on-resize approach would be a simple, viable approach for many applications.
7:32:58
loke``
slyrus: One problem I had with redisplay was that the scroll positions of all scroll-panes were lost
7:33:43
slyrus
I'm beginning to think that our scroll-panes are rather useless except for trivial demos
7:36:02
slyrus
But scrolling (and other sliders) are another good example of where we might interaction between the event loop and the command loop. Right now we can repaint in callbacks but I think redisplaying would be a problem.
7:36:51
slyrus
And we might want, say, a slider that controls how much detail is to be drawn or some other parameter, that causes not just the repainting of existing output records but new records to be created.
7:42:07
beach
I am still convinced that stuff that triggers redisplay should be synchronous with the command loop.
7:46:16
slyrus
sure, but you said changing a slider should trigger a command. Couldn't a resize do the same?
7:48:11
beach
So I maintain that redisplay should not be called from the event loop, without triggering a command.
7:48:25
slyrus
Call it whatever we want. But I want to change how my application draws things when the window is resized.
7:50:30
beach
But, yes, it seems that my problem with the proposed solutions is that the command loop was bypassed.
7:51:59
slyrus
Ok. I may be overstating the obvious here, but to give an example of the sort of thing that I believe we should be able to support can be demonstrated by opening your favorite web browser to a given page and resize the window and watch as the page is (redisplayed/redrawn). I would imagine we might be able to support that kind of functionality in McCLIM/CLIM, but it isn't obvious how to do so.
7:54:53
loke``
(defun call-in-event-handler (frame fn) (clim:execute-frame-command frame `(funcall ,(lambda () (funcall fn)))) nil)
7:55:21
loke``
I think I needed it that way to make sure that local lexical binds gets captured correctly.
8:02:58
beach
I am convinced that there are many aspects of modern GUI applications that are not covered by the CLIM II specification. And I think we should try to accommodate such aspects. But I think it should be done by using the stratified design of CLIM to create new components that behave the way we want, rather than altering the behavior that the specification requires for specified components.