libera/#clim - IRC Chatlog

9:26:53 White__Flame ** NICK White_Flame

12:44:13 rotateq jackdaniel: hm when i do '/join #ecl' it throws me into an empty buffer. strange

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:16:40 scymtym for untransformed bitmap images all of that should be skipped

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:19:28 beach And I could do the transformation myself if required.

14:19:46 scymtym i was trying to say that an optimization in McCLIM is required

14:19:57 beach Ah, OK.

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:20:46 scymtym should only be a few lines

14:20:54 beach I'll look into that, thanks!

14:20:59 beach So you don't like my idea of drawing to a pixmap?

14:22:03 scymtym sorry, what's the connection?

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:22:52 beach Provided there is an efficient way of displaying a pixmap.

14:23:48 scymtym right, that approach may also work

14:24:02 beach OK.

14:24:17 beach I guess I need to figure out when an how to apply the pixmap functions.

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:24:47 beach Oh, of course.

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:26:22 beach Right, if we had double buffering, I wouldn't need any of this I would think.

14:27:09 beach "periodically" as in you actually did what we discussed some time ago?

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:28:06 beach OK.

14:28:16 beach I'm off for 20 minutes or so. I'll read it later.

14:28:26 scymtym see you later

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:01 beach

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

14:51:43 beach Sounds perfect.

14:52:11 scymtym {FORCE,FINISH}-OUTPUT do nothing but notify the port of the request which is then handled in a slightly special way

14:52:54 scymtym thanks

14:53:27 beach And you backend is still alpha or beta quality? So not in the repository?

14:53:39 scymtym the tricky part is not drawing everything to the screen at 60 fps when nothing has changed while at the same time reacting to input events or drawing operations without latency

14:54:01 beach Yes, I can see that.

14:54:35 scymtym yes, still working on it. i'm pretty sure i have the architecture figured out, but i need lots of architectural changes in preparation which i have to consolidate and clean up

14:55:06 mcoll how do I redraw text to account for new window size? I amb doing (format stream ...) but when I resize the window the text stays wrapped at the previous window size

14:56:09 beach scymtym: So given that there is no ETA for the new backend, let me rephrase my initial question: How do I display a CLIM pixmap in a CLIM pane so that scrolling is tolerably fast?

14:57:34 scymtym beach: once you have the desired pixel data in the pixmap, i think MEDIUM-COPY-AREA would be the means of displaying

14:58:09 scymtym to tie that into output record replay, maybe make a custom output record type and call MEDIUM-COPY-AREA in the REPLAY-OUTPUT-RECORD method

14:58:49 beach scymtym: That's the information I was looking for. Thank you.

14:59:36 scymtym beach: i hope that works, but i haven't tried it

15:00:00 beach I will experiment some. But that was the general technique I had in mind.

15:03:10 beach mcoll: I believe someone wrote a pane class or something similar that will do reflow.

15:03:36 beach I think loke would be the one to ask.

15:04:10 beach And jackdaniel will know, but he is probably spending the weekend with his family as well.

15:04:54 mcoll thanks! I also just found (stream-end-of-line-action) which when set to :allow disables the wrapping, will test now

15:05:04 loke[m] Ask what?

15:05:13 beach about a reflow pane.

15:05:57 loke[m] Yes, I built the one. But I thought jackdaniel had a better idea one now?

15:05:57 beach mcoll: Sure, that's easy. Then it won't wrap and you will get a scrollbar instead.

15:06:19 loke[m] Sorry not, the one. Just one. My mobile keyboard likes putting in extra words.

15:06:56 mcoll yeah, I think that's enough for my purposes for now

15:07:14 mcoll loke: where can I get it?

15:07:15 loke[m] In my version, I simply regenerate the output record when changing pane width.

15:07:55 mcoll I have to understand the whole output record stuff, still don't understand exactly how it works and how to work with them

15:21:07 mcoll hmmm, how can I handle a click on something that has been drawn as a presentation type. So I have an item and it is drawn to screen using presentation types, I want to be able to click on it to toggle it, but afaik handle-event cannot be specialized for this

15:22:06 beach You might want to define a presentation-to-command-translator that changes how it is drawn.

15:22:54 scymtym easiest way is (define-command (com-toggle-item :command-table YOUR-APPLICATION-FRAME-NAME) ((item 'item :gesture :select)) (toggle-item item))

15:23:17 scymtym the :gesture :select part generates the presentation to command translator that beach mentioned automatically

15:23:31 mcoll thanks guys :)

15:23:36 mcoll sorry for all the questions

15:24:03 scymtym :SELECT is usually an alias for "left point button click" (might actually be button press or button release)

15:24:15 scymtym s/point/pointer/

15:24:22 scymtym don't worry about it. asking questions is fine

15:26:59 mcoll nice, it worked!

15:28:14 scymtym yeah, that's the part that makes certain types of user interfaces extremely easy and quick with CLIM

15:30:00 mcoll indeed, that was easy

16:49:46 jackdaniel I wrote only some proof of concept demo that show a reflow

17:01:23 mcoll is there a way to control the size of the presentation hightlight box?

17:03:47 mcoll I discovered the single-box option so that I get a single box out of a lot of text instead of small boxes, but I'd like to specify a bigger highlight box for some entries

17:05:42 mcoll ah, the bounding-rectangle stuff

17:13:58 mcoll hmmm, I cannot set text family to monospaced, it says "The following files should exist" and list a whole lot of files that *do* exist from cl-dejavu

17:25:50 loke[m] Use :fixed

17:29:22 mcoll :fixed doesn't work either, but :fix did

17:50:11 jstoddard_ ** NICK jstoddard

19:39:10 mcoll how could I refresh the rendering as soon as a promise resolves for example? I'm fine if it means polling from time to time. Is there any way to run a refresh from time to time and redraw on data change? How does data-binding work in McCLIM?

19:40:51 mcoll to give a little bit more context, I'm running some external commands wrapped in an lparallel future that I want to show when they are resolved

19:41:43 scymtym look at Examples/graph-toy.lisp for updating on external event

19:42:01 mcoll perfect, thanks!