|
From: | Ergus |
Subject: | Re: Question about display engine |
Date: | Mon, 9 Sep 2019 19:08:58 +0200 |
User-agent: | NeoMutt/20180716 |
On Mon, Sep 09, 2019 at 07:00:00PM +0300, Eli Zaretskii wrote:
Cc: Eli Zaretskii <address@hidden>, address@hidden From: martin rudalics <address@hidden> Date: Mon, 9 Sep 2019 09:39:13 +0200 > I fixed that, try now please (it is in savannah already). Thank you. Works now as expected. I'm still not convinced that it is a good idea to unconditionally run handle_face_prop_general from extend_face_to_end_of_line. It will penalize processing every line shown in a window even if no attribute processed is affected by a nil :extend attribute.The penalty is just a call to merge faces and look up the merged face in the face cache (which, under most usual circumstances, will always find an already realized face in the cache). If you are worried about face merging itself, then don't be: we do this in redisplay all the time when displaying buffers, except in the most boring cases (like buffer of all-ASCII text in Fundamental mode). And the alternative is IMO worse: it will require tracking all the face changes and deciding upon each change whether it does or doesn't affect the line extension.
Hi Eli: About this; I agree that the penalty should be negligible at the end compared to other things that happens on re-display. But after working on that parts I recognize that the actual algorithm for merge are extremely complicated and some parts are redundant. All the code is full of conditions and branch divergences and the design of faces infrastructure could be more efficient. Code that is used very often like "PRODUCE_GLYPHS" checks 3 if conditions every time (we should unify at least the if/else to bypass directly to the pointer, asserting that it is always initialized in terminal or gui). face_at_buffer_position and merge_face_ref are actually full of nested and nested conditional calls and even (direct and indirect) recursive calls. Some functions that could call merge_named_face I think they call merge_face_ref instead (with the extra checks and divergences). While other "low level" calls at the end also call merge_face_ref (probably for safety) ex get_lface_attributes, merge_face_vectors and so on. I understand that all this is probably negligible... but all that inhibits many optimizations very important these days like code inlining, branch prediction and vectorization. But also a big part of the code is needed just because the divergence between the tui and the gui code... if we unify the interfaces; then an important part of the code will be simplified and reduced and easier to maintain and modify.
[Prev in Thread] | Current Thread | [Next in Thread] |