freenode/#clim - IRC Chatlog
Search
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?
18:37:10
ck_
jackdaniel: I believe #742 can be closed now; also, #699 needs only a technical writeup and a normalization of the standard width/height values for all panes. Would you like me to put a diff as a comment?