freenode/#clim - IRC Chatlog
Search
4:28:08
loke
Not biking today, so that's annoying. One of the spokes on my wheels snapped when I was going downhill, and getting replacements has been a struggle
4:29:03
beach
Oh, that's too bad. I am not biking either, because we have those summer thunderstorms here in Bordeaux. Much worse than those in Sài Gòn.
4:29:05
loke
Seems like expensive wheels also makes for expensive parts... It's like 15 $ or so for a replacement, if you can find them from the distributor. Someone on amazon UK sold a single spoke for 50 punds
4:36:08
beach
I am almost finished with my specification of the SICL garbage collectors: http://metamodular.com/garbage-collector.pdf
4:36:51
beach
Still missing is the locking required for allocations in the global heap by the application threads, but I don't think that is problematic.
4:37:06
loke
(I'm checking the biggest online bike shop, and the popular wheels are around 200-350 punds
4:38:26
beach
The stuff you are good at is in the document now, so if and when you have time to take a look, I would greatly appreciate it.
4:39:23
beach
The GC chapter is a bit long, but there are several pages of figures and examples, so I don't think it is terribly dense.
4:43:36
loke
So in demodemo for example, one can run the "address book" demo, and then press return a few times to get the cursor to the bottom and then run the "describe" command.
4:50:53
loke
I realised there were off-by-one errors caused by the fact that the pane location (insice a viewport) could be set to non-integer coordinates
4:51:50
loke
That explains why for example my graphs (like a sine graph) in Climaxima subtly changed appearance as I was scrolling previously. Since the graph was repainted every scroll operation, it got repainted using slightly different (sub-pixel) coordinates.
4:52:22
loke
and since a sine wave isn't exact, the resulting pixel coordinates could differe by a pixel due to rounding
4:53:44
loke
It's a small bethod that changes the dehaviour of (SETF SHEET-TRANSFORMATION) to force the transform to an integer coordinate
4:54:49
loke
After figuring out that I need to do a "bankers" rounding, and properly deal with negatives (which the more simple ROUND-COORDINATE doesn't do) it started working. :-)
4:56:06
loke
Remember, the whole reason for all of this is to make scrolling using XRENDER work properly
5:11:30
loke
Right, but the issue I described applies to any medium which uses pixels. It is my opinion tha you _want_ to ensure that a pane can only be places on pixel boundaries, as otherwise your drawing on said pane will not be pixel-perfect
5:11:53
loke
In Climaxima you can see this by plotting a sine wave and then scroll up and down a bit. More visible on lower-res displayd.
5:14:56
beach
I am afraid I don't understand the argument. what does it mean for drawing to be "pixel perfect" and why would the integer restriction be enforced by McCLIM, rather than by the application that wants to use integer coordinates?
5:22:52
loke
It can only enforce it on what the applicaiton draws, but it's passed through the pane transformation
5:24:39
loke
Also, I notices that in my tests, teh pane sometimes starts out with a non-integer position. I saw the pane transform to be set to Y=1/4
5:26:05
loke
beach: Sure. But the question is: Can you actually think of any real-life case where support subpixel pane positions on a pixmap display? Every single test case that I have come across are cases where it caused visual defects, or simply prevented things from working right
5:27:20
loke
What my fix does is to still allow the transform to be set to arbitrary positions, but it's rounded to the nearest pixel.
5:27:58
beach
My thinking is the other way around. Unless I can see a good reason for restrictions, I would like to avoid them.
5:28:41
beach
No, I am absolutely not convinced. And I am not happy with the direction in which this is going.
5:29:21
beach
I need to go. I am a bit upset right now. I'll take a shower and so some house chores.
5:29:48
loke
beach: OK, I'll explain what the root issue was, and you can think about how you would prefer to see it solved?
5:31:25
loke
What I've been doing is implementing an accelerated way of scrolling. So, instead of simple repainting the entire screen whenever I scroll one pixel, I copy-paste (using Xrender) the content, which is super fast, and then request a repaint of the one pixel row.
5:32:24
loke
The problem with subpixel positioning of CLX panes is that the rounding then causes off-by-one errors when repainting.
5:32:42
loke
These errors are always there, but when you repaint the entire screen you can't really tell.
5:33:23
loke
But, when you keep one part of the screen and scroll-then-repaint another part, the two parts don't line up.
5:36:49
loke
beach: Please understand that I actually understand where you're coming from. Without putting too many words in your mouth, I think the concern here is that you feel that this solution is too heavy-handed. It forces unexpected behaviour in the sense that the user sets a given transformation, but end up with a rounded one, _but_only_sometimes_.
5:38:13
loke
It also leads me to think about an alternative solution... Since this optimisation of mostly of benefit to scrolling using scrollbars-mousewheel...
5:40:24
loke
so that if the original Y position was at coordinate 123.87, the resulting one would be 201.87. That would be cause any rounding in the drawing routines to round the same, preserving the subpixel position while not affecting output.
5:41:15
loke
But then the implementation would need to be done on the clim-core level, and not on the CLX level
5:43:23
loke
because it would allow me to control more about the circumstances unde rwhich the optimised scrolling code is called.
5:44:57
loke
You should, because had you not said what you did, I wouldn't have thought about this other approach
5:46:33
slyrus_
loke, I see some scrolling artefacts, e.g. in Scroll-Test-2, especially in the lower right hand corner of the panes. still, keep up the good work!
5:47:52
loke
slyrus_: I think that perhaps beach's idea (well, the idea he gave to me while I pretended to be him during my monologue) might actually be more stable.
5:48:40
slyrus_
Ok, cool. BTW, if you have time, keep in mind my naive ideas of how I'd like to see scrolling and zooming interact: https://github.com/slyrus/zoom-viewer/
5:50:24
loke
slyrus_: I'm not 100% sure what you are describing. Don't we have this already wuth transforms?
5:55:26
slyrus_
of course I could be using the APIs wrong, but I couldn't figure out how to get the sort of zooming and scrolling I'm after to work right. But, like I said, perhaps I'm just doing things wrong.
5:57:14
slyrus_
Ultimately I'd like to have multiple possible transformations, i.e. I'd like certain things drawn with one transformation, and others drawn with another, e.g. a map where mapped items can be zoomed in and out but certain features can be drawn with a fixed (or otherwise different) transform.
6:03:07
slyrus_
(zoom-viewer::zoom-viewer-main), use the sliders to zoom and the scroll bars to scroll
6:05:06
loke
are you using the usual scrolling mechanism for scrolling? (if so, that'll use my xredner version :-) )
14:57:34
loke
ebrasca: By writing an application for it. My heave learned a lot by working on Climaxima.
14:58:45
jackdaniel
ebrasca: some learning materials are listed in https://common-lisp.net/project/mcclim/