Hi,
In case anyone is runing the Qt port on Intel graphics hardware on
Ubuntu or similar systems and experiencing sluggish performance, a
suggestion is to run the application with the '-graphicssystem raster'
switch enabled. This yields greatly improved performance in my case.
--Alex Dobkin
On Wed, Oct 14, 2009 at 5:04 AM, Gubinelli Massimiliano
<address@hidden <mailto:address@hidden>> wrote:
Hi,
On 13 oct. 09, at 22:32, Norbert Nemec wrote:
In fact, I found a clear measurement that indicates a problem:
Running TeXmacs/Qt on my fairly modern notebook (fully
optimized compile).
I fill one page with plain text. Now simply moving through the
text with the right arrow (no editing!) brings up the CPU load
to 100%. Of this, 95% are spent in the X server. TeXmacs
itself only takes 5% of the CPU power.
I can confirm this observation. In my ubuntu virtual machine
(VirtualBox/MacOSX) the above protocol gives \sim 75% CPU load to
Xorg and \sim 23% to texmacs. You should check that you do not use
cairo since at the moment the cairo rendering is slightly
unoptimal in QT (explicit and naive double-buffer).
On my mac the load remains reasonable (30% which should include
the GUI load also since the total CPU load is not much higher).
Proprer implementation of check_event require knowing if there are
pending key events in the queue and this is not possible in Qt (or
even in Cocoa). Moderns GUI API explicitly discurage looking at
the event queue so we should design a different mechanism to
reimplement what it is currently done in the X11 port.
best
max
I tried activating the code in check_event. The display is
incomplete now, but the CPU load is down to 30% and TeXmacs
feels fully reactive.
Seems like this optimization is crucial not only for slow
machines after all...
Greetings,
Norbert
Joris van der Hoeven wrote:
On Tue, Oct 13, 2009 at 05:14:02PM +0200, Álvaro Tejero
Cantero wrote:
I didn't notice any problems, but TeXmacs-QT feels
slower already when
typing at the end of 3-line paragraphs.
That is shortcoming of the current Qt version:
interrupts during the rendering phase have not yet been
implemented.
Now that delayed_event has become cleaner, maybe Max can
fix that one too.
Is there any more quantitative way to test performance?
This is rather a matter of reactivity. Hard to measure.
Best wishes, --Joris
_______________________________________________
Texmacs-dev mailing list
address@hidden <mailto:address@hidden>
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
address@hidden <mailto:address@hidden>
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
address@hidden <mailto:address@hidden>
http://lists.gnu.org/mailman/listinfo/texmacs-dev
------------------------------------------------------------------------
_______________________________________________
Texmacs-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/texmacs-dev