freenode/#clim - IRC Chatlog
Search
3:05:00
ck_
loke: I don't know, it happens to me every once in a while that I just wake up at 3 or 4 for the span of a couple of months
3:11:59
no-defun-allowed
Oh, I have to rewrite the printer because it - is terrible and I could use the CL pretty printer instead, - needs to emit presentations, and - is generally terrible
3:13:19
no-defun-allowed
But I intend to follow up with a presentation-based renderer for Markless and also probably a viewer for a secret program I'm working on.
3:15:24
no-defun-allowed
But I did make file reading/writing and added variable replacement and scope explication, which is enough to step through some simple problems.
4:13:02
ck_
are you aware of that study group knuth lead, with a sort of deobfuscation or decrypting challenge as one of the problems?
5:24:20
ck_
loke: relating to the command stuff, I'm taking a look at #736. Have you found anything on this in the meantime I should be aware of?
5:25:48
loke
I'm positive that it used to work back in the olden days. But I have tested up to really old versions + really old versions of CLX and I can't reproduce.
5:26:19
loke
So perhaps it only works under certain circumstances, and when I saw it work, it worked in that special circumstance.
5:26:38
loke
Finding otu what the circumstance is woul dmake fixing the bug easier, but unfortunately I have nothing to provide.
6:59:24
scymtym
i tried double buffering for the inspector: https://techfak.de/~jmoringe/new-inspector-double-buffering.ogv - found two X resource leaks in the process
7:08:36
jackdaniel
the prime sin of it is not that it doesn't work right but that it does the wrong thing
7:09:31
jackdaniel
I have plans for double buffering, but doing it before xrender migration would make the work much harder
7:10:01
jackdaniel
I think that incremental redisplay is somewhat broken, I remember there were tickets on github about it
7:11:09
scymtym
ideally, this would use incremental redisplay to only re-create the changed output records and then use double buffering for a flicker-free repaint
7:11:18
jackdaniel
n.b current thing will most likely break with: rectangles with uniform color and with text
7:12:04
jackdaniel
I'm not sure if you've seen my presentation, but I have plans for animated output records
7:14:28
scymtym
the cool thing about leaking X resources is that it takes down your whole session, not just your McClim window or CL process
7:15:08
jackdaniel
I've introduced ^cleanup variable to free allocated resources when we leave the gcontext
7:15:58
scymtym
as i said, the picture is stashed into the plist of a pixmap. i don't know how you would release that in a general framework
7:17:23
jackdaniel
regarding animated output records, what bothers me a little is the fact, that bounding rectangles are suposedly immutable
7:17:45
jackdaniel
*but* all formatting seems to ignore this requirement (i.e formatting-table relocates output records)
7:19:28
scymtym
isn't our policy to deviate from the spec where it makes sense and document the differences?
7:20:20
jackdaniel
if bounding rectangles are immutable, you may cache the bounding rectangle sets for repainting
7:21:30
jackdaniel
also, that could potentially mess up the spatial trees in tree-output-record history
7:28:41
loke
jackdaniel: wrt your thoughts of double buffering: I was thinking about it too, and I figured that it would make sense to draw everything to an XRender picture, and then always just copying that picture to the screen. This would also make it possible to reimplement optimised scrolling where the entire screen is not repainted, but only the part that scrolled in.
7:29:11
loke
(I implemented that in past, if you remember, but it failed because I'm an idiot and didn't realise that you aren't guranteed to have the content of windows preserved when overlapping)
7:33:27
jackdaniel
the problem is that we still have a) normal drawing routines, for which such hack "works", b) xrender routines, for which it does not (because they use their own picutre which is now swapped)
7:33:47
jackdaniel
that's why I've said that sorting things out while we still support both rendering modes at the same time will be more work
7:35:06
jackdaniel
also, speaking of current rendering macro, it is expected from the programmer to specify changed regions themself
7:40:39
loke
When I did the experiments with optimised scrolling, I did request repaint of only the small part that was revealed, as opposed to *EVERYTHING* which was used previously. Is this the same thing?
7:42:15
loke
OK, then I think I understand. That also means that whatever you are thinking about for Xrender is pretty much the same as what I'm envisioning. That's great.
7:44:56
loke
In my previous render work, I did one for DRAW-LINE that was half-finished. I could restart that.
7:45:54
jackdaniel
one note, please make it a pull request per finished operation (or even smaller), not a big chunk "migrate to xrender"
7:46:15
loke
My version had support for dashes but they were ugly. I used the clip mask for that, and it turns out that when I applied rotation on the clip mask, there was no antialiasing
7:46:43
loke
Anyway, it's a bit hazy now so I'll just restart it and share the result with you when I have something. Should be a decent weekend project.
7:46:46
jackdaniel
we have a software rendering library too, maybe you could use that (and improve that code as well)
7:47:44
loke
Oh and about merge requests. Each one will probably need several rounds of discussions/critique, so I see them as individual projects almost. The ellipse implementation will be fun.
7:48:11
jackdaniel
yes, that's why I've saaid one PR per operation or even smaller PRs where it makes sense
7:49:26
jackdaniel
regarding double buffering, here is a thought I had a few minutes ago: we already have medium-finish-output and medium-buffering-output-p (with its setf method)
7:50:47
loke
jackdaniel: that sounds too easy. I don't know that code to have an opinion, but I fully expect there to be something that stops it from being simple.
7:51:23
jackdaniel
well, *the thing is* that we do not buffer output at all, the hard part is implementation
7:51:38
jackdaniel
I'm wondering if it is sufficient as the api (given we hint that in documentation)
12:59:13
loke
jackdaniel: Are you there? I have a question w.r.t. xrender... Do we already store a picture representing the entire window? The font renderer (both of them, afaik) allocates its own, which is a bit of a waste.
13:38:08
loke
jackdaniel: I was checking how the render backend handles complex shapes, and it uses the PATHS library (part of cl-vectors). I didn' tknow about this library.
13:39:07
loke
It implements the necessary code to break paths and polygons into simples shapes, which is what is needed for xrender as well. I've already gotten the basic line drawing working with xrender, so now I'm looking into leveraing PATHS in the same wasy as the render backend.
13:42:57
jackdaniel
instead of copying code over maybe it is possible to reuse render methods? or refactor them into reusable components?