freenode/#clim - IRC Chatlog
Search
9:43:51
scymtym
i haven't done any exploration either, but 7max had something planned that might help with that: https://github.com/7max/log4cl/issues/12
13:07:14
jackdaniel
right now when we draw things (on output recorded streams), we apply transformation to coordinates upon recording and when we replay them, we simply call it with +identity-transformation+ (with transforemd coordinates [and ink])
13:10:04
jackdaniel
this approach has a flaw that we can't use hardware acceleration for transformations (and while for coordinates it is fine, we simply pre-compute them and there is nothing wrong with that where applicable), this is problematic if we have a non-uniform ink
13:11:31
jackdaniel
because we either transform it like other things during recording (and that is inefficient since it is done in software pixel-by-pixel), or we need to record medium transformation, apply invert transformation on coordinates (depends on drawing primitive) and then perform transformation in hardware
13:13:03
jackdaniel
while right now it is not a big deal, we'll have this problem anyway when we'll want to emancipate sheet transformations like slyrus and beach suggest we should
13:13:27
beach
Is this a case where the specification gives us a choice between storing the transformed coordinates and storing the transformation with the original coordinates?
13:14:10
jackdaniel
I think so, but I didn't look for it yet. I'm just sharing now how this is limiting some optimizations
13:15:33
beach
"The effect of the specified "user" transformation (composed with the medium transformation) must be captured; CLIM implementations are free to do this either by saving the transformation object or by saving the transformed values of all objects that are affected by the transformation."
14:05:54
jackdaniel
from bad news: I'm hestitant to bury myself in mcclim for another few weeks to work on clx to adjust to the alternative behavior (at least now)