Given the speed and many cores, maybe there are now new things that would be feasible in TeXmacs?
And if so, what might those be?
Does Apple Silicon open up new opportunities for TeXmacs?
One idea is to have most editing operations be instant by having expensive formatting done in the background on another cpu core. When the expensive formatting is done (or partially done), your display will update to reflect that.
Separating the typesetting computation from the UI is on my todo list. Not completely trivial, but interesting to try. This could potentially benefit any multicore system, not only Apple’s. But not clear how much. It would certainly be something needed to target webasm and browsers efficiently, since there you cannot allow the typesetting to block system responsiveness.
3 Likes
So you would have a quick typesetter that does block the UI and a high quality typesetter that doesn’t? When the high quality typesetter result is ready, it replaces the quick typesetter result?
That was not my plan. Just split the editor/typesetter and the UI in different threads, the input go from the UI thread to the editor thread, it is processed and changes propagated to the document rendering, and this is sent back to the UI thread for visualisation. This would make easier for example to rewrite the UI in javascript to run in the browser, still keeping the editor compiled to wasm and running in a worker thread, for example. But I think also the desktop version could become more responsive, since while the user interact with the UI (e.g. menus, etc…), the editor could still perform computations. The decoupling could also simplify a bit the logic of updating, but for the moment I have only vague ideas and some experimentation is needed.
But how would that ensure that TeXmacs can keep up with fast typing while still displaying what you type in real-time?
I do not feel myself that TeXmacs has serious slowness problems. The codebase is stable since early 2000 when machines where much slower. Probably some profiling can identify the bottleneck for specific documents but overall would be difficult for me to identify the areas to improve. Hints or some measurements are appreciated. If one get’s serious about improving we need a standard way to measure improvement, otherwise unduly optimisation will only make the codebase less maintainable and maybe introduce bugs without being able to quantify the improvements. My aim is just to decouple various parts to use the common multicores we have. TeXmacs editing use a lot in-place modification, so this limit a bit the amount of parallelisation one can enjoy. But I can imagine that UI/typesetting/rendering can be split in three threads. Especially one can render one document while already performing the next editing operation without too much modify the current logic. Still this require already substantial amount of work.
I don’t recommend improving the speed of the typesetter while maintaining correctness, but rather, to create a typesetter mode that does a lot less (e.g., nothing that requires looking at the whole document) and is much faster.
This could be done using a flag to the current typesetter that indicates whether expensive operations should be skipped or done more efficiently. The result may not be correct, but it is only temporary.
This is exactly where the problem lies. A simple operation as inserting one single character has the potential to change all the line breaks in the same paragraph and all the page breaks in the rest of the document (hence the speed-up in “papyrus” mode: no page breaks).
Something that could perhaps be done is prioritize the breaking of the content displayed on screen and perform the rest later on. However, given that there is already a pretty good solution (papyrus mode), the amount of work needed to implement this and the very limited number of people who could do it, I don’t see this happening very soon.
1 Like
You don’t need to look at the whole document if it is ok for the result to be incorrect.
And incorrectness is acceptable for something that is temporary and will be fixed soon.
I fail to see how this would work. Perhaps you can clarify.
- How would this “incorrect typesetting” be calculated in practice?
- What use would it serve?
- How would it be used to calculate the final typesetting?
Take word wrapping as an example.
You might be using the highest quality word wrapping for the document.
Incorrect typesetting could use a more efficient word wrapping.
When you pause your typing, correct but more expensive typesetting would be done. (Alternatively, correct but more expensive typesetting would be done in parallel on another core so that its result would be available sooner when you pause your typing.)
So when the high quality word wrapping is ready, what you see on the screen would change from the low quality word wrapping to the high quality word wrapping.
Similarly, you could have incorrect but more efficient pagination, figure placement, etc.
There are various issues: first it is not clear what are exactly the computations which require more time, I guess is not word wrapping, but without actual measurement of the cost of certain operations we risk to spend a lot of energy in useless optimisation. Second while partial computation sounds appealing, it is not clear how to implement it, since it will produce a lot of moving content on the screen, while the various successive approximations are computed, also how many approximate rendering are needed? In the X11 version of TeXmacs there were some optimisation in place which would redraw the area around the cursor, before redrawing the full document, and stop redrawing if some input arrived and the document needed to be typeset again. I would tend to think indeed that it is the redrawing which is expensive (i.e. going from the boxes to the pixels). But again, without actual measurements we are just doing guesswork. Nor it is clear to me that partial redrawing is automatically better than no redrawing at all. It would be useful to see some example of this in action, but I’m not aware of any software which perform such kind of optimisation, nor of any research paper which discusses the tradeoffs.
TeXmacs uses expensive algorithms that take time proportional to paragraph and even document length. This is done to produce higher quality documents.
It also uses expensive algorithms for simplicity — to make the code easier to write and debug.
I use TeXmacs on a long notes file and it is slow on my 2015 13inch MacBook Pro.
As for stuff moving all over the place, some things like figure placement and pagination could keep their current positions until the high quality typesetter computation has been completed. So movement may occur, but probably not during fast typing.
Document -> Page -> Algorithm -> Sloppy might help, it is worth trying. It is the manual equivalent of the procedure you would like to see automated. If you decide to give it a try, it would be nice if you tell whether it makes a difference for you.
What I propose would give you the best of all worlds. Sloppy would be used during fast typing and professional would be used when you pause your typing.
Still what I propose might help you now, and also give potentially useful information to the developers (of course it depends on many variables but it might be a start).
I’m using screen mode, which doesn’t have page breaking. But some things as simple as pressing return to insert a line are not instant.
I tried changing word wrapping from professional to normal, but it is still not instant.
Even though you might expect editing in screen mode to be instant, some things still require whole document scans (to keep the code simple).
How long is your document? Do you see any difference going from professional to normal? From normal to sloppy? @mgubi are there measuring tools available to users for this ? I have seen a debugging-bench tool, which might be interesting for @amichail - would that be? Maybe the only information one needs to do some debugging is the number of pages in @amichail’s document and possibly the number of tables and pictures, so @amichail does not need to share anything?
Finally, are we sure that screen mode does not have page breaking?