libera/#clim - IRC Chatlog
Search
11:39:22
jackdaniel
should sheet-native-region return (transform-region (sheet-native-transformation sheet) (sheet-region sheet)), or should it account for clipping of the parent?
15:16:48
jackdaniel
mkay, I have a prototype where we don't throttle output by transformations (i.e in coordinate swizzling demo), but we can see the output progress \o/
15:25:48
mrcom
Re sheet-native-region: From an API purity standpoint I'd lean towards including clipping. It's advertising the return is a region, so make it a real region. If all you want is bounds-ish then ask for that.
15:26:55
jackdaniel
in either case it is a region, but if we include clipping it is possibly smaller
15:27:15
jackdaniel
re efficiency, whatever we do we are partially covered by caching the native transformation
15:28:19
jackdaniel
in principle clim is expected to handle /at least/ rectilinear rectangle and rectangle-set regions with this regard
15:29:12
jackdaniel
so if it becomes a bottleneck, then we could enforce the sheet region to be always a rectangle
15:30:13
jackdaniel
so, to make it clear, you think that it would be better for sheet-native-region to be clipped by all sheet ancestors?
15:32:15
jackdaniel
I think that rectangles are reasonably fast; clx backend does a very poor job for region intersections that can't have a canonical form
15:34:34
mrcom
IIRC, didn't appear to be collapsing the rectangles, always applied each of the parent rects.
15:35:39
jackdaniel
region-union specified on rectangles canonicalizes them, so they are not overlapping and they are xy-banded
15:37:40
mrcom
Hmmm. Didn't appear to be what was happening in my case. I'll have to go back and look more closely. Maybe I was inadvertedly sabotaging the specialization.
15:38:06
jackdaniel
if you conclude that it is mcclim bug, please let me know, that would be pretty serious
15:39:24
mrcom
Performance, not a bug. And I vaguely remember thinking something like "they can't really combine them because may need to X later..."
15:42:37
mrcom
Applying a transform against the previous result appeared that it was stacking the transformations. Got very slow after a few such.
15:43:30
mrcom
If, instead, I created a new transform against the parent each time, it was much better.
15:45:31
jackdaniel
transforming a rectangle should produce a new region without bundled transformation. transforming patterns had this issue
15:45:50
jackdaniel
(I think that I've already pushed the change for that, but it may still be in my current work branch)
15:54:32
mrcom
I was/am, essentially, trying to build in a smart graphviz viewer that can handle 100ks of nodes and edges.
15:55:54
jackdaniel
standard-tree-output-record-history arranges records in a spatial structure, so that should be reasonably performant (i.e we'd reply only the current viewport)
15:56:24
jackdaniel
by that I mean - accessing the history to repaint, I'm not sure how other parts of mcclim would handle that
15:58:02
jackdaniel
I'm expecting to merge a branch with various rendering improvements in a matter of days (eventually weeks), so if you could produce a program I could use for testing, then I could look into that use case too (without promises)