Hi,
On 14 juin 09, at 20:34, Alex D wrote:
Hi,
I've been experimenting with the Qt port lately on Linux. I'd just
like to mention I get much better performance with -graphicssystem
raster in case people are not aware of this option.
There is a cairo renderer available in the repo. We should experiment
which one is faster (Qt or Cairo).
I've briefly profiled the rendering code, and noticed TeXmacs does
three complete repaints and one partial for, essentially, every key
press. It also seems to rebuild the main menu after every key press
and this causes Qt to refllow of the whole window.
You should be aware that in the current Qt port the mechanisms that
blocks redrawing is user input happens is disabled. The X11 port is
more sophisticate in this matter and I suggest you to look at that
code to see how far we are in the Qt port.
I've actually went in and disabled the extra whole-window repaints
so only the partial repaint was done, and it wasn't rendering
correctly :-(.
Also, I implemented native font rendering with Qt, which was quite
easy. I think this is the way to go. The result looks much better
and should also be quite a bit more efficient than the present
implementation.
I'm very interested in that. How did you implemented native rendering
of fonts in Qt? I've spent a lot of time trying to do this in Qt/Mac
and while I've managed to do this it is not really straigforward (Mac
cannot read Type1 fonts directly). Can you sent me your patches?
Best,
Massimiliano
Sincerely,
Aleksandr Dobkin
On Sun, Jun 14, 2009 at 11:11 AM, Norbert Nemec <[email protected]
> wrote:
Hi there,
after doing a bit more profiling, I am beginning to realize just
*how* inefficient some of the central C++ code in TeXmacs is:
a) For the central data types (string, tree, etc), nearly all
routines should be defined as "inline" in the header files. The
cleanest and simplest solution that I see would be to introduce
additional files like string.inc.hpp that contain many of the
routines that are currently defined in string.cpp and include this
at the end of string.hpp. That way, the header file would not become
cluttered, but the compiler could still do heavy inlining on these
routines.
b) Profiling indicates that the program spends a tremendous amount
of time on reference counting and deallocation. Moving to a garbage
collector would significantly simplify the code and should result in
quite some speedup. Especially for interactive programs, garbage
collection is the fastest memory management strategy available since
all the collecting is simply happening in idle time and the time
critical code does not need to worry about deallocation at all.
c) The string class is a significant bottleneck. Every time a
(char*) is converted, the data is copied to a newly allocated
location. In most cases, this could be avoided by simply copying a
pointer. This would mean that the string_rep class would need to
carry a flag on whether the space is "owned" (and should be
deallocated) or just "borrowed". I certainly is a non-trivial task
to sort this out, but I believe it would be the single-most-
rewarding detail in optimizing for performance.
... just my analysis for the moment. I know that it would mean
significant work to work on any of this...
Greetings,
Norbert
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
