libera/#clim - IRC Chatlog
Search
9:16:30
beach
(clim:bounding-rectangle* (clim:make-pattern-from-bitmap-file "...")) => 0 0 5098 7012
9:16:31
beach
But (clim:bounding-rectangle* (clim:transform-region (clim:make-scaling-transformation 0.4 0.4) (clim:make-pattern-from-bitmap-file "..."))) => 0.0 0.0 2039.2001 2804.8
9:21:41
beach
(bounding-rectangle* (transform-region (make-transformation* 0.4 0.4) (make-rectangle* 5098 7012))) => 0.0 0.0 2039.2001 2804.8
9:36:31
beach
scymtym: Aside from that, the pixmap technique works quite well. Scrolling is instantaneous, even when I don't restrict the region.
10:12:32
beach
I had a different problem that led me to believe that the second value was wrong. Now everything works.
10:27:45
beach
Heh, thanks. Lots of work left on this application, but I am just doing a little bit every now and then. My main project is still SICL.
10:30:05
beach
Not this time: https://gitlab.com/informatimago/cl-suggested-projects/-/blob/master/projects/document-recovery.org
10:31:09
beach
But it is for the same learning experience. I plan to scan physical dictionaries from Vietnamese to English in order to incorporate the contents into my database.
10:38:55
moon-child
'The document may contain scripts that are unknown to the system, and it may contain different fonts and sizes of these scripts. It is assumed, however that the number of different distinct glyphs is not too large, say at most a few thousand, and more often a few hundred, different glyphs' what about logographs?
10:41:42
moon-child
logographies may have larger charactersets. Are they not intended to be supported?
10:43:06
beach
The size of the character set is different from the number of distinct glyphs that appear in a document. But, I the intended workflow may have to be altered if that set is extremely large.
10:59:35
beach
http://metamodular.com/example.pgm is an example of one page of a document that I want to process.
11:46:46
jackdaniel
did anyone look at the document outlining the plan to improve our geometry module? if there are no critical remarks then don't blame me for implementing something utterly wrong (;
11:47:54
mcoll
where can I see this document? (not that I have the knowledge to review it right now, I'm just curious)
11:48:25
jackdaniel
it is more a short summary of the module and idea for canonical forms for results of various operations
11:49:51
mcoll
hmmm, japanese characters show up as squares, I guess it's a missing font support problem and not a text rendering problem tho
11:50:36
jackdaniel
we're bundling dejavu fonts, if they don't cover some character then it is rendered as a square
11:56:09
mcoll
is it possible to specify a fallback font for when a character is not available? or it is only possible to fallback when a font is not available? (i'm not even talking about mcclim here, but I have no idea how that works generally)
11:56:39
mcoll
I'm pretty sure browsers fallback to other fonts when a character is not available in the main font, using font families
11:58:15
jackdaniel
see the file "Extensions/fonts/freetype.lisp" and navigate to a class font-replacement-text-style
11:58:26
jackdaniel
I've implemented it for freetype, but that should work just fine with truetype fonts
15:13:30
mcoll
I was checking the Examples/graph-toy.lisp program to handle events (by suggestion of scymtym yesterday, and while it works, the screen flickers on every redraw when doing (redisplay-frame-pane frame 'main-display) is there any way of making it less flickery?
15:31:02
beach
So "redisplay" means to clear the pane and recreate all the output records from scratch.
15:32:19
jackdaniel
and repaint, while now means the same as replay, should in fact mean copy pixmap from the backbuffer
15:34:35
beach
The flickering is due to the fact that the pane is first cleared, and then the output records are created and drawn by the display function.
15:35:10
mcoll
I see enabling :incremental-redisplay helps with the issue tho, I guess it avoids clearing the whole pane?
15:36:21
beach
Incremental redisplay re-creates only the output records that have changed, provided you tell it how to distinguish them, but currently, McCLIM does some other magic with incremental redisplay even when you don't tell it anything.
15:53:10
jackdaniel
beach: by "other magic" do you mean that McCLIM does something that is not implied by CLIM II specification?
16:36:43
jackdaniel
I believe that I've pointed out operators mentioned in the specification. I don't think that we do anything beyond what the specification says
16:37:20
beach
If you turn on incremental redisplay, and now new output record is equal to an existing output record, there should be no difference from having it off.
16:38:43
jackdaniel
well, the spec is a little more fine-grained than that, the operator in question is called redisplay-output-record (http://bauhh.dyndns.org:8000/clim-spec/21-2.html#_4287)
16:39:05
jackdaniel
either way to the best of my knowledge we are not implementing anything (regarding incremental redisplay) beyond what is specified
16:42:30
beach
So why is it, then, that when incremental redisplay is off and I redisplay a lot of text, it takes forever and it scrolls for each character I output, but when it is on, it is very fast and does not show anything until the entire output is done?
16:43:02
beach
Why do I notice the difference, even though no existing output record is equal to any new ones that I generate?
16:44:53
jackdaniel
isn't the purpose of incremental redisplay to have the same effect /after/ displaying, not during the operation?
16:45:19
jackdaniel
the slowness is due to a different issue - we call repaint-sheet when the output is about to be scrolled
16:46:16
beach
Forget about the scrolling. It displays each line separately when incremental redisplay is off and it does not do that when it is on.
16:46:19
jackdaniel
I mean - we have bugs, but incremental redisplay doesn't do any magic - if you turn off drawing for the time of the display of function and then replay the output you'll have the same effect
16:46:51
beach
Where in the specification do you see that this is a difference between the two? I mean, maybe there is such a place, but I have never seen it.
16:47:15
jackdaniel
I didn't say that there is a difference, so I'm not sure why you try to frame it as if I had said that
16:48:26
beach
Still, unless such a place exists in the specification, I don't understand why it behaves differently with respect to showing the lines in the window when it is off and when it is on.
16:49:15
jackdaniel
as I said - we are too eager to do some stuff when incremental redisplay is off, it is /not/ due to any magic implemented in the incremental redisplay
16:50:14
beach
Fair enough, the "magic" is when it is off then. All I wanted to say that there is a difference in behavior that I can not justify from my reading of the specification.
16:51:30
beach
But I sincerely think that lines need to be painted as they are generated, but that this needs to be the case also with incremental redisplay on.
16:55:18
jackdaniel
I don't have a clear idea what and how this should be done; perhaps non-incremental redisplay should wait until the display function finishes and then show the image and incremental redisplay should display things as they go (interactively) - preferably with help of double buffering.
16:55:54
jackdaniel
or both should display things as they are "drawn" (also with double buffering) unless explicitly controlled by the programmer with WITH-OUTPUT-RECORDING
16:56:50
beach
The first possibility would be strange if you have a display function that (say) pauses between each line so that displaying everything takes a very long time.
16:57:52
jackdaniel
that's true, on the other hand if the application is written in a "CLIM" way, then display function should only show the application state and the heavy lifting should be implemented as part of the command execution
16:58:21
beach
So the "magic" I was first referring to would then be the fact that incremental redisplay currently does not show output records as they are either created or reused.
16:59:43
beach
All I am saying is that I have observed a difference between when incremental redisplay is off and when it is on, and no new output record is equal to an existing one, that I can't justify from reading the specification.
17:00:57
jackdaniel
updating-output (as specified) is expected to compute the set difference and decide the minimal set of things that need to be replayed
17:01:56
jackdaniel
and in order to know that it needs to execute all continuations (i.e the display function)
17:02:27
jackdaniel
so this doesn't seem like a trivial thing to do (to show lines immedietely as they are drawn)
17:18:25
jackdaniel
one interpretation is that you consider what I'm saying as idiotic and that wouldn't be nice; so I'll try to think about another interpretation in spare time