Actually, I spent a few hours hacking the cairo renderer to work with the Qt gui on Linux. When I finally got it to work, the TeXmacs windows would be all gray and the white page with text would blink into existence momentarily when a key was pressed but then the screen would turn gray again. I could'nt keep Qt from overwriting the drawn image with gray after every repaint and gave up.
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 don't fully understand. You're saying all the full-windows redraws are not an error? I assume only only having the one partial redraw after a key press is the correct behavior. 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? > I'm using QFontDatabase::addApplicationFont() to register fonts with Qt. Then I use setPixelSize() to set the point size. I guess this won't work correctly with font's that have multiple optical sizes like Computer Modern, but personally I think Computer Modern is a terrible typeface, and should be replaced with Times as the default. Qt Linux can handle type1 (.pfb) fonts just fine, so it's not a problem for me. The font files should be renecoded as OpenType and TrueType to ensure that they work on all platforms. Reencoding fonts iself is easy. With FontForge I was able to reencode and merge the GPL'd Base 35 fonts (Times, Helvetica, Palatino, etc), Liberation, and DejaVu into TeXmacs' format. TeXmacs uses FreeFont internally now to rasterize glyphs to bitmaps, so OpenType fonts will not pose a problem for the X11 port. But we will also need to have the fonts in pfa or type42 format so they can be embeded in postscript. The only inefficiency with native Qt font rendering is that Qt has to do complicated script anlasis, shaping, deal with kashidas, etc for every character draw operation. But I don't think this is a big deal. I can certainly work on a patch for this, if you believe this is the way to go. On Sun, Jun 14, 2009 at 2:36 PM, Gubinelli Massimiliano < [email protected]> wrote: > 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 > >
_______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
