libera/#clim - IRC Chatlog
Search
12:54:57
beach
I am attempting to write a McCLIM application for manipulating large-ish gray-level images. Currently 2500x3500 pixels, but I would like to do 5000x7000 at some point. I used the technique jackdaniel told me about to turn the PGM into a pattern and that works fine. Displaying the image takes only a few seconds. However scrolling is unbearably slow. Each small amount requires the entire visible area to be cleared and redrawn.
12:55:23
beach
Is there a better way to do this with, say, pixmaps, so that scrolling will be tolerable?
12:58:04
beach
By the way, this is the "recommended project" described (among other places) here: https://gitlab.com/informatimago/cl-suggested-projects/-/blob/master/projects/document-recovery.org
14:16:19
scymtym
beach: the code for drawing patterns to the screen is very slow because it applies two expensive things to each pixels: 1) the medium (and possibly pattern) transformation 2) the translation from a design coordinate to the corresponding ink
14:18:13
beach
Sounds good. So how do I draw an untransformed bitmap image? As a matter of fact, I may need for it to be transformed, but not very often.
14:20:05
scymtym
what you probably can do, though, is CHANGE-CLASS the pattern you into some custom subclass
14:20:39
scymtym
then implement a CLIMI::%COLLAPSE-PATTERN method that skips the transformation and ink computation
14:22:41
beach
If I draw my image to a pixmap, then those expensive transformations would be applied only once, and not each time I scroll.
14:24:37
beach
I don't know whether they are part of the replay protocol or redisplay protocol or something else.
14:24:39
scymtym
but generally, i would prefer it if McCLIM figured out the best way for the current backend to draw a pattern to the screen
14:25:50
scymtym
but drawing to a pixmap should totally work. my double buffered CLX backend draws everything to a pixmap and periodically displays that
14:27:44
scymtym
i explained the method a few times, i will find an explanation in the log after finishing the previous thought
14:29:33
scymtym
i was going to say that the optimization for drawing patterns will still be necessary since drawing the pattern to a window and drawing the pattern to a pixmap (which is in memory on the server side) are almost identical
14:45:19
scymtym
i can't find a suitable discussion to link to. so let me try to summarize the idea again
14:46:40
scymtym
in my approach, double buffering is something a port does for its directly mirrored sheets. those sheets have a mirror and a backend-specific off-screen buffer of the same dimensions as the mirror
14:47:57
scymtym
for sheets, drawing operations are only allowed from the thread that "services" the event queue of the sheet. drawing operations target off-screen buffers (possibly belonging to a mirrored ancestor of a given sheet)
14:50:01
beach
The performance when I load an image for the first time is not a problem. I can then stick it in a pixmap.
14:50:09
scymtym
after drawing, the port is notified that the off-screen buffer is now "dirty". when at least one off-screen buffer is dirty, the port plans a deadline for a "frame" so that no activity results in no drawing to the screen and continuous drawing to sheets results in drawing to the screen at a given maximum frame rate
14:50:22
beach
If I can just make the REPLAY part faster, so that scrolling is tolerable, that will be enough.
14:50:45
scymtym
when the deadline for the frame is reach, the port stop processing input events and displays all dirty off-screen buffers on the screen
14:51:25
scymtym
this has to be coordinated with all threads that might draw to the off-screen buffers