freenode/#clim - IRC Chatlog
Search
4:36:45
slyrus_
but I'm thinking that ultimately the cl-vectors rendering strategy is a losing one. probably just need to bite the bullet and write the xlib calls to render the bezier designs.
4:42:11
beach
I take into account all possible constellations of points and lined within a scan line.
4:46:33
slyrus_
I haven't benchmarked it extensively, but my approach certainly feels much faster and the visual results are less wrong, but, I agree, it's probably still not the ideal approach.
4:52:25
beach
I am sorry, I am confused, because I am engaged in intense work on the lambda list parser, so I am not following the details of all the McCLIM improvements.
4:56:02
slyrus_
Like I said, I doubt my approach is optimal, but it is 1) much faster and 2) less visibly wrong
4:57:08
beach
It was designed to create pixmaps for individual music elements. These pixmaps are then what is used at runtime, and that is very fast.
4:57:46
beach
That code was never meant to be used for rendering in each iteration of the event loop.
4:58:43
beach
That said, I am not sure that my technique is intrinsically slow. Again, I didn't pay attention to performance because the code would be invoked only the first time that a score needs a particular music element at a particular size.
4:59:39
beach
So, I am in favor of doing what you do. Later, we can figure out whether there is a better rendering method. Better, as in faster and more accurate.
5:00:15
slyrus_
yes, and your method doesn't need to go away, it just shouldn't be used by the CLX backend at the moment.
5:00:37
slyrus_
and a modification of your approach to generate the xlib calls would probably be a nice thing
5:01:39
beach
But I think for Clovetree (Gsharp v2), I will count on having anti-aliasing available and not render to pixmaps.
5:02:41
beach
Since pixmaps overwrite each other and music elements overlap, I need to use a lot of tricks to make it look good without anti-aliasing and transparency and such.
5:03:14
slyrus_
ah, you've run into my problem of the "halo". I was hoping there was an easy fix for that :)
5:03:37
beach
So, for example, if I have several note heads in a chord, if I were to draw each note head separately, some pixels of one would be erased by another.
5:04:36
slyrus_
well, maybe, but, again, I was hoping that was fixable. I got around the problem of wiping the whole bounding rectangle, which is a step in the right direction.
5:06:20
beach
I am afraid I don't know what "wiping the whole bounding rectangle" means in this context. Again, I am sorry for being so disconnected.
5:08:33
slyrus_
your code drew a white rectangle and then the bezier design over that, wiping out what was there before. when you get a moment, run the bezier drawing tests in drawing-tests.lisp, then pull my branch and try it again. you should see the differences.
5:09:37
beach
There is absolutely zero reason to maintain my code for rendering at the event-loop level.
5:10:37
beach
It was designed for one particular use case, as I explained above. Your approach is much better.
5:11:32
beach
I'll be back in 30 minutes or so. Then I may have to hurry and go to the store while the weather is still acceptable.
6:54:06
beach
flip214: I still prefer to go between two of the numerous showers they predict for today, since I am on a bicycle, and I always have three bags (one behind me, and two on the handle bars) when I get out of the store.